Open ta-lind opened 5 years ago
matheusd
commented
5 years ago My only remark about this is that on desktops it's usually the vertical space that is more limited than the horizontal space. Eg: on laptops you'll have plenty of horizontal space for the sidebar+content, but not to show the full contents of a given page and then you'll require vertical scrolling.
ta-lind
commented
5 years ago Assume this is in regards of limiting desktop viewport width? I see the point, however a widescreen variant that’s actually saving the vertical space is something that can be addressed after this (as it needs further groundwork). For example, in the past when I've worked with dashboards for industrial use that go big in width (across screens) – the key is a modular approach. Where instead of scaling elements (or element groups) to width, rather the grid has a repeating logic to it and elements are then re-arranged on it (so staking horizontally for as far as they can). Something in lines of this:
Otherwise we'd have items e.g. rows that would still take up the vertical space + be stretched unusefully long.
ta-lind
commented
5 years ago Status on these.
Launcher
[x] Logs
Inside Wallet
Preview: https://xd.adobe.com/view/4f6828c6-71b4-491f-5224-579b840b2743-3959/ Specs: https://xd.adobe.com/spec/3bd71ab7-4a8e-43d4-5ab8-2ad3dd3500ee-4de6/
Bit of insight and instructions:
When implementing these, be aware the design approach for decrediton has been desktop-first so far, thus the responsive views for smaller sized viewports will first focus on getting a kind of basic, usable and visually hygenic solution on the table. Focusing mainly on a minimal responsive approach, and keeping any changes/adapations as simple and quick as possible. Obviously some modules/elements can't simply fit or scale, so in those instances some adaptive solutions will be needed.
The work can be started by defining the key viewports. The largest (and current) is 1180 px, which has a content area of 740 px. Notice that currently when re-sizing Decreditons window to even larger sizes, in some of the views elements scale with it. This should not happen. Instead if the view is scaled further in width all elements should stay within the content area. When the navigation is closed, the content area should retain the same spacing what it has by default between the navigation, and change it's position slightly to the left ( following the navigation (e.g. slide 2)).
Second smaller breakpoint is 768 px, with a content area of 668 px. This is a common tablet size. When the user scales down to this, nav. menu should trigger closing into smaller state (or be closed by default if opened in smaller window). Also when the user expands the nav. menu and clicks on another view, the nav. should then close (when transitioning to the next view). When the nav. is expanded, nav. menu should stay on top of the content area (kind of as right now) without affecting any elements there.
Smallest mobile sized breakpoint is 375 px with a content area of 355 px. In this instance, the navigation has a new variant. The mobile nav. is locked in the bottom corner of the viewport, and by default in a closed state. Due to size limitation, the closed menu contains only 4 key items (as well hamburger for opening complete navigation) those being: Overview, Transactions, Governance and Settings. When opened, the complete navigation covers entire viewport, as well displays block sync status. Menu items in the full nav. variant are of same size as in other viewport sizes, although have different vertical spacing (and selector height) for better fit. Menu icons in closed state are slightly larger for ergonomic reasons (w/ 24px bounding box). Content area always continues vertically below the navigation.
As a follow-up to this issue, each view will receive a visual design example, presenting and describing how to elements should be layed out and confirming whether there's any adaptions needed. These will be posted as separate weekly issues.
Also you may notice the action buttons are right aligned. These are currently in progress https://github.com/decred/dcrdesign/issues/64 and will be posted as a separate issue once covered in all views (so should not be addressed yet).