Client Visual Design Direction

[ninavizz]

Shd get done by mid-December, so all assets are available to devs once post-Alpha cleanup is complete and (fingers crossed!) we're ready to plug ahead into Beta.

Visual Design =

• Typography
• Proper visual framework layout/grid proportions & styles
• Colors!
• Branding!
• Clear action/buttons schema (primary, secondary, tertiary)
• 5 button states (active, hover, focus, static, disabled)
  • Regardless of how richly Accessibility may or may not be built into the Beta Client, it should still be designed now for implementation as soon as robust Accessibility is made a higher priority.
• Activity & notification messages
  • Dialogs system
  • Transient messaging system
• Total design system defined

Visual design is not content design. That's its own ticket. Content design is the writing/styling of written content, and all final icons and illustrations. For the interaction design and user testing, placeholder icons are used to evaluate semiotics in comprehension. Placeholders may or may not graduate to final design. Visual design is a higher priority completion need, as content may always be swapped-out later... but changing styles is a PITA, the deeper we're in.

Nice description of Visual Design (as its distinguished from other UX design activities) on usability.gov

[ninavizz]

Client interaction design, largely done. Form-factor and implementation of branding, pretty solid with in the black-and-white wireframes; but totally open to exploration of other directions! Nothing locked-down, yet. See wireframes posted on Workstation UX Project Page, to reference above progress.

• No coding skills necessary to explore visual design options
• Any format that communicates thinking/ideas, valued!
• Project's f/t designer (me!) has and regularly uses full Adobe suite, Sketch, Invision Studio, and Omnigraffle.
• Project's f/t designer (me!) can also review HTML/CSS/Javascript things
• Client is coded in QT, and if anyone desires futzing with the QT code itself, by all means—go for it!

The QT Client has its own repo.

[eloquence]

For the 11/28-12/12 sprint, we've agreed to focus on:

• main screen design (source list / message view)
• sign-in screen design

For now we're just aiming for at least two static drafts for review with the whole team, to build agreement on the visual design direction.

[ninavizz]

This Issue restricted to ONLY the above, and the first-pass "batch" for a team review. Will close Issue upon full team review the week of 10 December, and include feedback in comments.

[ninavizz]

First Pass Review

» Deliverables «

Present for crit: @eloquence @heartsucker @redshiftzero

• Analogous app screencaps helpful
  • Jen spotted the one she'd started from, in her early PSD mockup.
  • @redshiftzero Were there things in that direction you'd like me to continue to explore, or to pick-up on for these explorations?
• Designing for camera-capture obfuscation not advisable; if ppl can record your screen through a window in a room, you've got much bigger problems than their ability to capture diceware ID'd source tips. Worst-case, they can get the OfficeCreepo privacy shields.
• Hexablues graphical BG treatment "sick" (yay!!)
  • SD logo rotation is wonky
• CleanWhite has nicer right-pane
  • Peeps like absence of patterning in the right-pane's background
    • Didn't quite know what to make of the LouisVuitton SD repeat BG in Hexablues
• Number flags didn't cut the mustard
  • Ambiguity with "What does this mean?"
  • Value-add to experience?
  • Wd need indicator for what the number signifies, then oohdoggie that is some busyness...
• Explore more with left column for interactive starring in Sources
• Likely best plan for team to target the CleanWhite out the gate, then to add-in graphical things and transparency bg stuff w/ colors, as an enhancement
• Per-user starring not tracked on backend; goal for workstation is to keep all user data on just the Workstation, so that all being ephemeral a more compelling user need wd need to surface to justify all the work.
• Discussion of XFCE theming; end-of-life risks in adopting a 3rd party theme. Yet Another Thing To Break, also. designer shrugs and still wants windows to step away from the 1998 kludge they're stuck in, today.

Nina's Next Steps

• Combine best-of the two directions
• Do some iteration on how starring in its own column on the left w/ clicked and unclicked state would look.
• Do further refinements... files? That damn top bar?

[ninavizz]

Second Pass Review

» Deliverables «

Notes on this round's mockups:

• Bub-01, Bub-02, and StarCol-01 all show different stylistic approaches to doing convo bubbles
• Bub-03 shows the direction from Bub-02 extended to factor-in files
• ClickThru3 shows what messaging to Sources and internal messaging among just the newsroom team, could look like as both visible in the same window. Also demonstrates option of showing all journalist messages in a solid bubble, and working with the ux paradigm of "Sender = white, Recipient = dark" for bubble coloration.
• Things changed since last review: Interactive starring in its own column on the left, added
• Logo rotated
• LouisVuitton-ish patterning of messages pane, removed

Present for crit: @eloquence

Summarized feedback

• Nina: interactive starring in the left column with the dark "theme" of this direction, difficult to do; wd be much easier on a lighter theme (action-item: developing a light-on-white iteration of this direction, for review post-holidaze)
• Erik has Opinions™ on aesthetic options... not noting here, as to not bias feedback from @redshiftzero and others (whom have yet to weigh in)
• Nina, of course, also has her own Opinions™
• Both sets of Opinions™ gathered by Nina, will be working with in next round of mockups
• Could be usability issues w/ great risk, if team/source messaging sharing the same pane are not done right; internal messaging w/in a source is its own feature, however, and not likely to fit into scope until after Beta

---

Requested by @eloquence to focus on for next drop, as team could benefit from seeing this stuff sooner rather than later for what's up in the next sprint:

• What could a ligher-themed version of this design direction look like?
• Work with discussed aesthetic things on Messaging
• What is the downloading file experience? Messaging from client and Qubes, both.
• What does opening a document look like?
  • How will that message display? What will is say?
• Concurrent messaging & bottlenecks via slow or down Tor (summarized in Design Problem: Process Server Logjams, "FYI, this is a thing" and "Error" messaging #28)... ugh.
  • How to do?
  • What is surfaced to users in words, animations, flags, or all 3?
  • How to handle when there's multiple things to communicate at once (eg: multiple state processes fail to sync with the server) with both written messaging, calls to action, and UI state reversions?
  • Sketch some things to review in next crit

[ninavizz]

This is now a sub-task within #31

Problem

We're building this thing called the Qubes Workstation Client. A general design direction needs to be established for the Visual Design/aesthetic things.

Considerations

• Abundant discussion (above) from November, through today.

Acceptance Criteria

• Mockup or animation of general direction agreed-to by team, with open-issues yet to be tackled as individual issues, summarized.

[ninavizz]

Closing, and final design to be reflected in delivered #36

---

Notes from 17 Jan UX meeting, where the two mockups that led to this closure were discussed:

• Nina shared 2 new VisDe mockups as updates from the last review with Erik, nicknamed David Bowie and Elton John
  • Consensus among attendees was a preference for Elton John, despite Nina having more warm-fuzzies for David Bowie... but the critiques were entirely valid, and we don't want SD to look like a Slack wannabe.
  • Erik flagged complexities around progress bar things.
    • Nina clarified intent of long-horizontal animated bar (pink or teal) at the top, citing the Medium.com pattern that it's simply a generic network-activity animation untied to performance or any task progress.
    • Nina also added in desire to have proper progress-bars at some point, for file downloads, but that those would be separate and done inline with the file in the UI.
    • Note: Because animations in prototypes are a bit of a PITA and were a low priority to get spot-on correct, I also did not prioritize 1:1 implementation of that animation in the Studio Prototype that shows loading animations. Just FYI.