Organizing the design process

Mitu

Hi,

I'm writing with a concern I have recently and an idea. Actually I see recently that a few core apps have been updated, however it seems like in terms of design some chaos starts to sneak in.

A little hint of it is between the latest clock app and open store. Both of them have bottom sidebar now, but there are slight differences between them (font size is one thing, the other is that in clock only active tab has a text visible, in OpenStore all of them). It is a little of a problem, but it is shows a problem that needs to be addressed before it gets bigger:

The design consistency

What is happening now is that every developer just does something as he feels it looks the best. The problem is that there is little corelation in what different developers do in different apps. I believe that it is very important for the core apps and system UI to be consistent. Canonical new that and that's why they created lots of guidelines and documentation. I must admit, that they did not manage to keep all apps consistent perfectly (partially because their SDK was a moving target, and they did not manage to put that much resources in the core apps to update them often) - but they had the guidelines and the team, who defined those guidelines and was creating the apps' designs.

The proposal

That is why I would like to suggest a workflow for discussion and approving the designs. It would look like this:

The design guidelines should be posted somewhere (or the Ubuntu Touch's documentation should be linked). I am strongly for accurate adoption Canonical's guidelines and mockups as official currently and later on, aftere 16.04 is landed, the guidelines can be discussed - probably in accord with moving the Ubuntu specific UI widgets to QQC.
There forum "Design" is created, which is used to showcase, discuss and approve designs (It's the simplest idea, maybe there is an option to use the better tools for the process).
Every change in app's UI (adding new feature, changing the design), needs to have it's topic opened by the developer. In the opening post the dev explains the changes and either presents the screenshots of the changes he had done or asks for inspiration/ideas/designs. It is open for discussion then and everyone can make suggestions. It is also checked across guidelines and review by the design team (who needs to accept the changes for the core apps and system UI - let's say by a defined number [ACCEPTED] posts from the design team).
During the discussion dev updates and presents the corrected design - it could be also reasonable to include the beta click package, so that people can not only see the changes, but also experience them in action. This is not required though, as many designs will be probably first prototyped, and then implemented (especially for the bigger feature, not just let's change the tab bar or throw in a new switch).

I believe that such design team could also review the current state of apps and suggest their changes/create tickets on GitHub.

The team

Yes, I know that there is no such team right now. I'm not a proffessional designer, though I believe I could help by actively look through designs and making suggestions - maybe also from create a few mockups if I find time for it.

The other thing is gathering that team: I feel like Ubports should more clearly express that they are looking for the designers - maybe a bar on the homepage, subpage informing about the need for design team members etc. (of course if you decide to do so).

Let's open the discussion!

jsnjhn

That is an excellent idea!

I am a graphic designer who just moved to Ubuntu Touch and I'm loving it so far. I've been wondering how I could help the community in some ways as I am not a developer and know nothing about coding.

If you're idea does come to life in a way or another, I'd be glad to give some of my time to review and tweak some visuals.

However, I think there's a balance to find so that everyone is happy. I think it is important for developers to respect the Canonical guidelines, after all it is because of the them that the design is so beautiful. On the other hand, we want things to go forward and make the process easy and simple for everyone. I'd be afraid the some developers get frustrated with your proposition.

chregi

I love that idea!

The designer guidelines that the canonical people made is for me a good balance between density of text/buttons, space and usability.

For me in todays fancy new designs it just needs to look good. Developers have many good technical ideas, but lack the experience in designing something that looks good/consistent (if it works, why change it?).

For me the point to make many mockups and to discuss them and adjust them accordingly to feedback and use it as a base for everything would be necessary and would help all those other unity8/7 spin-off.

But I think in order to make it possible designers must help developers create these mockups. or create a lego like framework in gimp ?

One of the ideas I have is to create a unity8/7 design group that defines the future/base of the unity like Distributions and bundle all of these different/convergence?! goals ?

sverzegnassi

That's a great proposal, we'd like to follow up with some plan.

Documentation is expected to be available soon on docs.ubports.com, once the transition from the old wiki to ReadTheDocs will be concluded.

For the moment being, it's available at https://github.com/ubports/phone-docs/blob/master/en/apps/design/index.md
It's fully browseable through GitHub.

One of biggest concerns is how to coordinate the two concurrent efforts (by developers, and UX designers), without compromising the quality of the process.
While we want to avoid awful visuals like red scrollbars or mixed typography [1], we need to ensure that coordination between developers and designers can be smooth as possible. I'd suggest to avoid any cross-posting of pull requests both on GitHub and this forum, since it might get easily insane to keep the discussion on the right track.

What we could do (and it's welcome):

Promote the participation of developers on this forum, and enable a channel where app maintainers and designers can discuss their ideas with no friction. This should work as a place where we can explore multiple solutions and proposals, without bloating GitHub with informal discussions.
Promote the participation of designers on GitHub. Feedbacks and bug report for UI/UX questions are welcome in the bug tracker, and we're currently planning to mark any existing design-related issue with an 'UX' label for better discoverability. We might also offer a repository where we could store all the official mockups and existing documentation, with a full history of changes.
Ask code contributors to answer a few short questions whenever they prepare a new pull request. This would work as a first filter for "unconfirmed" changes, and is what the 'unity8' project used to do back at the time. An example of the questions can be found at [2].

I already see some reply by designers, and we absolutely appreciate it.

I'd like to ask all the designers on the forum to let us know if they're interested in the creation of this new group. If so, please feel free to reply here.

I'd also like to survey your familiarity with the typical tools used in open source projects and, in particular, GitHub.
Most of the developent happens there, and many design teams (including GNOME and Canonical) currently use the platform for design discussions with a discrete success[3].

Knowing your preferences on this would help us to support you with the most effective workflow.

As a final note, I'll try to get in touch with Canonical to see if we can get some documentation for the various UT projects, since not all the docs have been publicly disclosed during the last years.

Thanks for your posts, and in particular @Mitu for the proposal.

=======

[1] An interesting insight on early design approach in Microsoft
https://medium.com/microsoft-design/a-brief-history-of-design-8641bd186e00

[2] A current example of a merge proposal / pull request: https://code.launchpad.net/~josharenson/unity8/dashboard-manager/+merge/319522

The list of questions included at the link above:

* Are there any related MPs required for this MP to build / function as expected? Please list.
* Did you perform an exploratory manual test run of your code change and any related functionality?
* If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP?
* If you changed the UI, has there been a design review?

[3] As a reference, both GNOME and Canonical coordinate their design processes on GitHub. The topic has been nicely disclosed here:
https://design.canonical.com/2017/04/designing-in-the-open/

sverzegnassi

On a sidenote, we indeed haven't done our best yet to provide all the information about our needs for UX.
The website is currently going to be refreshed, so we'd ask you to stay tuned for further updates

As you all properly pointed out, one of first goals is to provide consistency. Or, at an higher level, coherence.

At the moment we're approaching a transition from Ubuntu Vivid to Xenial, and we will be tied to a different toolkit (QtQuick Controls 2, shortly QQC2[1]).

Our effort is to port the Suru design to QQC2; in this regard, we're creating a new style for the components. Here's a very early video, the style is based on Vanilla Design[2].

https://www.youtube.com/watch?v=0ahCT7yqr08&feature=youtu.be

With the new toolkit, which offers less control on how components behave, and all the features that convergence brings, including the ability to run apps that hasn't been designed for Ubuntu Touch, we can expect some obstacle in fully implement the current set of specifications.

Our hope is that it could turn in an opportunity to refresh our Suru specifications.

The full documentation for the current Suru design is not available or, in some parts, outdated (mid-2013, when Suru was still using those odd gradients).
The same documentation available on docs.ubuntu.com has never been completed during the last four years.

In the meantime, we have seen the raise of new UX trends, one of the controversial components (the bottom navigation) has been officially adopted by the Material guidelines, and Canonical decided to drop its Ayatana project (i.e. Unity 7) and adopt the GNOME 3 HIG.

What we need is help and guidance through these multiple inputs, in order to fix some of the current issues in usability, and eventually validate the design of new UI components. In a longer term, we might want to support an effort to revisit the current design guidelines.

I saw you've been interested by the recent changes in clock-app.
Feel free to open a new issue, or join existing discussions at: https://github.com/ubports/clock-app/issues

Thank you again!

======

[1] https://doc.qt.io/qt-5/qtquickcontrols2-index.html
[2] https://github.com/ubuntudesign/vanilla-design