diff --git a/docs/designer/imgs/basic-layout.png b/docs/designer/imgs/basic-layout.png new file mode 100644 index 0000000000..b8e402262e Binary files /dev/null and b/docs/designer/imgs/basic-layout.png differ diff --git a/docs/designer/imgs/basic-layout.svg b/docs/designer/imgs/basic-layout.svg new file mode 100644 index 0000000000..fefe75784d --- /dev/null +++ b/docs/designer/imgs/basic-layout.svg @@ -0,0 +1,208 @@ + + + + + + + + + Header + + + + Current page + + -> Opens Left panel + Opens Right panel <- + + + + + + + + + + Left panel + [.section-panel-left] + + + Right panel + [.section-panel-right] + + + + diff --git a/docs/designer/src/design_language.md b/docs/designer/src/design_language.md deleted file mode 100644 index fd6fcfb1de..0000000000 --- a/docs/designer/src/design_language.md +++ /dev/null @@ -1,31 +0,0 @@ -# Why a design language? -Humans have an innate understanding for common, predictable and repeatable concepts. Our brains are, in fact, hardwired -to take advantage of such phenomena, which is sometimes taken to great effects in optical illusions for example. - -Patterns emerge when concepts and actions, interlinked, construct a predictable outcome. With a common design language, -we hope to achieve such predictability, and supply an innate understanding of user interaction. - -The goal isn't to have one and only design language, but to encourage new themes/interfaces to take similar steps on their -design processes. - -## Predictability and user experience -A good book implies meaning, perhaps through environmental storytelling, or any other thought exercise that assumes -a conscious, and rational reader capable of processing information. Not just present it. -The same is true for a good UI, it shouldn't be explained, there should be an innate understanding. - -### User Interface Universal Language -Web technologies as a whole contain a set of constraints for organizing web pages. This implies that all web pages have -a common structural basis. - -Users accustomed to surfing the Web know which user interactions are acceptable and which aren't. -The key puzzle is how users come to know these restrictions of their Web UI. This is the crux of any -accessible Web page, an hierarchy needs to be followed as well as common standards. - -### Canons of page construction -The aforementioned comparison between books and Web pages isn't just a coincidence, given the resemblance between the -two mediums. From their presentation to fundamental theory, it's only natural to apply core book design ideas to the Web. - - -### User customization - - \ No newline at end of file diff --git a/docs/designer/src/guidelines.md b/docs/designer/src/guidelines.md new file mode 100644 index 0000000000..635a228dc1 --- /dev/null +++ b/docs/designer/src/guidelines.md @@ -0,0 +1,38 @@ +# Design considerations +Humans have an innate understanding for common, predictable and repeatable concepts. Our brains are, in fact, hardwired +to take advantage of such phenomena. Patterns emerge when concepts and actions, interlinked, construct a predictable outcome. +This basic idea should always be employed into the design of a user interface, because it inherently supplies an innate +understanding of user interaction. + +So, just bear this in mind. Try not to reinvent HTML elements, use them properly. + +The designer docs are intended to help out in the development processes of both the Core components, and Plugins. +With an emphasis on the frontend side of things, of course. + +## Basic layout +_Bear in mind **any** of the following assumptions are based upon the **default theme**, your mileage may vary._ + +The layout is subdivided in 4 distinct areas: +- **Header** + - Left panel ~~checkbox~~ button :) + - **Left panel** + - Main instance link / header 1 + - Right panel ~~checkbox~~... I mean, button... + - **Right panel** +- **Current page content** + +![GNU social's basic page layout](../imgs/basic-layout.png "The basic layout of GNU social default theme") + +Each one of these areas **are selectable** with CSS by **using a limited set of classes**. You can use whatever classes +you may want, but bear in mind that any external code made by someone else other than yourself may not account +for your specific class names. + +### CSS classes reference + +| Name | Function | Dependencies | Examples | Sub-classes | +|----------------------|----------------------------------------------------------------------------|--------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------| +| section-panel | Side panel | - Preceded by a checkbox hack (hide/show panel); | Left panel `\App\Component\LeftPanel\templates\left_panel\view.html.twig`
Right `\App\Component\RightPanel\templates\right_panel\view.html.twig` | `section-panel-left`, `section-panel-right` | +| section-widget | A sub-section of a page, commonly a template block of a component / plugin | None | Login template `\App\templates\security\login.html.twig` | `section-widget-title`, `section-widget-subtitle` | +| section-widget-title | A template block's title | - Part of a `section-widget`; | Settings template `\App\templates\settings\base.html.twig` | None | + +_**still in construction...**_ \ No newline at end of file