Discussion: Do we need a UI/UX guide for developers?

[pnbecker]

Many people are developing for DSpace which is great. Nevertheless, we want that DSpace look and feel like one application. We want to avoid situations where one feature looks totally different from other features or behave completely different (UX). For example we use the semantic colors from bootstrap (primary, warning, danger, success) for buttons, panels and other elements. Other useful information would be if there is a minimum width we try to optimize DSpace for. And for sure, there are many more information we should provide.

I would appreciate to hear from others, what they think: should we come up with a UI/UX guide for DSpace? What information should it contain? What unwritten rules do we have currently and what rules are we maybe missing?

[mwoodiupui]

YES.

One thing it should include is recommendations for accessibility. The v7 UI is pleasingly colorful yet had many cases which were distinct by color but indistinct by value, making use difficult for people with certain types of vision. And I've had to repair a few places where e.g. a control was structurally a link but styled to look like a button, which is confusing when using a screen reader. Perhaps the guide for these conditions is simply "it is important to test with an accessibility tool and fix what it reports."

Personally I am not a very good UI designer, and I would appreciate reasonable limits on my freedom to make something ugly and hard to use. A good style guide leaves me with fewer things to think about, because those decisions are already made.

[tdonohue]

@pnbecker and @mwoodiupui : We have a very basic start to this guide in the documentation at https://wiki.lyrasis.org/pages/viewpage.action?pageId=313851976
(This was begun during the 7.0 development process in a separate page at the time, but has been moved to official docs)

It's not complete or perfect because we do not have a UI designer available to us to write a more thorough guide.

I'll also admit, it's very difficult to enforce, because enforcement has to be done manually (all reviewers/testers must be aware of the guide and do a manual check...and as we know we don't have enough reviewers). That said, it's a starting point, and we can reference it to report bugs for pages we find that don't align well with the guide.

Overall, I agree with this idea. I'm just pointing out the difficulties we've already faced with building such a guide.

[hieramsee]

The question in the headline, in my opinion, misses an important point: the creation of a consistent UI/UX design. Only then can a guide be created.

Such a guide would benefit all users because it ensures a consistent development of the DSpace UI. Additionally, a living style guide with a component library can significantly ease the work of developers.

DSpace currently uses Bootstrap, a CSS framework and JavaScript library for general components. However, Bootstrap is not a complete design system for complex web applications. This is especially true when there are specific requirements in DSpace, such as integrating the corporate designs of various institutions, which necessitates merging two different design systems for each project.

Ideally, UI/UX designers and developers work closely together from the beginning. Designers handle the creation of components, the overall look of the application, as well as user scenarios and navigation structures. UX design is the concept behind the interface between software and human beings. The design is developed gradually with drafts and prototypes/user tests before the technical implementation begins.

In reality, however, it is often the other way around: Technical developers have already developed and designed an application themselves until it reaches a certain complexity. Then, they realize that the user-friendliness is suffering, meaning that people do not understand and use the software and its functions well. Only then do they bring in UI/UX design experts. A common misconception is to believe that design is something that can be added over a finished application like a coat of paint. Since UI/UX design is not just superficial aesthetics but a communication concept, retroactive optimizations can also require deeper changes. The same applies to accessibility.

For a highly developed application, the question arises: Should optimization begin with solution proposals (designers) or with problem analyses (user tests)? Based on my experience with DSpace projects, I would recommend starting with the fundamental optimization of the design system.

The reason for this recommendation is that UX design, like programming, often involves errors that lead to many additional issues. It makes sense to eliminate the underlying errors first. This automatically resolves many subsequent errors. Similarly, in UX design, if the operation of individual components is unclear (e.g., input fields requiring special handling or various button types), this leads to further confusion and can disrupt entire workflows. If all components are consistent and universally understandable, this often resolves other usability problems as well.

Therefore, I recommend first creating a consistent design system and then (or in parallel) a living style guide.

Here is a brief introduction to living style guides: https://launchscout.com/blog/what-is-a-living-style-guide, and here is a nice example of a living style guide on the topic of "Buttons": https://doc.wikimedia.org/codex/latest/components/demos/button.html