This time, I am bringing you a basic manual that is intended to serve as a UI Kit and as a reference of best practices for developers. The context and use is to have such a manual on an intranet or some other place to which a Company’s developers and programmers have access. This is a proposal in which I created the contents of the manual myself and also designed the whole graphic part.
The visual appearance of this manual is inspired by typical instruction manuals for household appliances, Ikea furniture, etc. precisely to give the user a sense of familiarity. We are used to finding in a printed instruction manual a quick access to the solution of a problem (mounting a shelf or a new graphic card, for example) and that is precisely the effect we want to achieve in the users of our manual. That they read it quickly and are able to understand it, assimilate it and apply it to the projects in which they participate.
The manual is supplied (but not shown in the screenshots) with a basic UI Kit, based on the principles of ‘Atomic Design’ that developers will use to build their applications.
Wireframes of the first iterations that were carried out are shown below.
Finally, there is a list of tips that I added in text mode as extended documentation, apart from the visual PDF manual that I have shown you.
Header (Logo + Menu):
Logo: The left half will always be used for logo and claim (if any).
Menu: Horizontal by default, sub-menus trying not to pass the 3 levels rule. Otherwise check structure (card sorting). Centered or left-aligned. In some cases you can align the login / user data / settings to the right. As a general rule, menus should not have more than 7 main options, including login, user and settings. Avoid additional vertical menus.
Content: we take use of the whole viewport width, applying default margins. No maximum width containers, especially when there is a large amount of information to display (control panels, dashboards). Maximum width (container) only for HD screens (1280 and above), to avoid readability problems (too long paragraphs).
Tables: always use the whole viewport width. Make the tables responsive, either by setting certain columns (actions) + horizontal scrolling fixed or by converting to vertical format. In cases where tables or contents are difficult to display properly on mobile, show a warning saying something like: "this screen is not optimized for mobile devices, please view it on a wider screen instead". Same idea for old or unsupported browsers.
Data (cell) editing is achieved using the pencil icon. As a general rule we will use modal windows. If there is a lot of data to edit from that row, we will use large modals. In general, for desktop we will use a maximum of 4 columns (big screens) and a minimum of 2.
Icons: the use of icons other than font-awesome, glyphicons etc. is recommended. Depending on compatibility requirements, jpgs/pngs may be used for legacy browsers, and svgs with the possibility of animation for more modern browsers.
For other types of elements, we recommend reviewing the criteria of the Material Design and/or Human Interface Guidelines.
And that’s it. As always, I hope you like the new content and more importantly that it is useful. Soon you will have new projects available to analyze. Stay tuned!