Server: Consistency of interface elements

Created on 21 Apr 2020  Â·  13Comments  Â·  Source: nextcloud/server

Is your feature request related to a problem? Please describe.
Currently, the UI feels incostistent.

Describe the solution you'd like
Nextcloud is already using Bootstrap tooltips, are there any plans to rollout Bootstrap (or similar framework) for the entire UI?

This will help to make the UI consistent and will allow to use Bootstrap themes.

Describe alternatives you've considered
Consider using Material UI or similar front-end framework.

0. Needs triage design enhancement needs info stale

Most helpful comment

so I'm not duplicating my work by migrating to material/bootstrap and implementing a11y on top of it.

IMO, Vue implementation of Bootstrap is doing pretty good job in the space of a11y.

Oups, sorry about this one, you're right!
I looked the bootstrap docs, not the vue-bootstrap. My apologies :)

And I agree with you, this is hard work, but that is what we do :)

Isn’t better to spend more time on new features and not reinventing the wheel?

That's one of the oldest developer question :)

I'll stop now, because I think we covered what we wanted to say, and it seems we just have different visions on the use of external libs (and those long texts are exhausting :hot_face: )
So thanks again for sharing it, it took quite some time, but even if I still don't fully agree, we at least are on the same page towards unifying the UI and making sure we have nice components that ease up the development :)
And that is all that matters! :hugs:
Stay safe!

All 13 comments

cc @nextcloud/designers đź‘€

I feel @jancborchardt old answer is still applicable here.

We are working on making Vue-based components for Nextcloud: https://github.com/nextcloud/nextcloud-vue
See a demo of this at https://nextcloud-vue-components.netlify.app/
As this is used by more and more apps, it will feel more and more consistent as well.

@rafenden could you share which parts exactly you feel are inconsistent? That would help fixing the actual issues. :)

Having a library of Vue-based components for Nextcloud is a step in a good direction, but it might be not enough.

Using an existing design system brings a lot of benefits, and these are:

I suggest making a POC which implements Vue Material or Vue Bootstrap for at least one app and I am happy to volunteer my time.

That POC could help the community to make an informed decision whether brining in a design system could benefit the Nextcloud project.

Sounds very interesting to do a PoC! I'd prefer Material Design over Bootstrap as it's more universal and has really good rules we tend to already follow.

@nextcloud/vuejs @nextcloud/designers what do you think? :)
Also, which app would it be – @rafenden any preference?

Having a library of Vue-based components for Nextcloud is a step in a good direction, but it might be not enough.

So, let's counter argument here!
Thanks for making those suggestions.

  • Nextcloud have a UI identity already. The design have been unified and standardise across the last years and frankly, I don't agree with your "the UI feels inconsistent". I'm obviously a bias here, but for all the apps we support (we cannot of course manage nor enforce all apps), you find the same features, ui and structure we use in all Nextcloud.

  • Material is incredibly wide. They supports tons of features, and we absolutely don't need all of them. As a product/project, we have to push towards a dedicated direction, and allowing us to use all kind of UI elements in our apps will not create a more consistent UI. Because we need to use similar components when the goals are similar.

What our library is doing is basically exactly this. But we only manage the components Nextcloud needs:

  • Consistency: This is the goal of our design system too, and the goal is successful to my opinion. Still to improve, especially by continuing improving/moving the apps we support to vue
  • _Themes_: We already have our own theme engine. Once IE11 is dropped, changing variables will be as easy (if we want this feature of course)
  • _Familiarity_: This I completely go on your side, having a feeling you know this place is a great thing. Unfortunately, I disagree with your statement: "Many users new to Nextcloud are migrating from Google Apps". WHile lots of users comes from google, because they're everywhere, google web is far from implementing their own material ui. Expecially on google drive which is our main point of comparison. Ok for people coming from mobile, but as a fair comparison, i'd take our mobile apps then. Which are built according to the Android Material UI too :)
    For the web ui, Drive implements some parts of material, but lacks a lot of it. Same for Gmail, which have a completely different UI than drive. Calendar is probably the best student here, and looks like a 100% material ui design :)
  • _UX_: Yep, we also spend a good amount of time for this. https://xkcd.com/927/
  • _Less code to maintain and less dev work required_: Yes and no. For that, the design system we'd have to take would have to fill 100% of our needs, otherwise we'd have to modify it. Work with them and create fixes/patches that others might not like. Having our own allow us a pretty great freedom :wink:

And last but most important point:

  • Accessibility! While the material designs are a great accessibility ressources documentation, the implementation of the vue-material lacks a lot of it[0], by a lot!
    Just looking at the tabs component for example[1], there is not a single aria-controls, aria-selected, no automated deactivation of tabs, no keyboard arrow navigation, no labelled-by. Our tabs component (sidebar) do all of this automatically and out of the box :)

So as a statement for my part & my opinion then: migrating to another library like bootstrap or vuematerial is not something I want. We'd definitely lose to the change and I'm convinced having a small set of very well written components is the simplest way to go for us. We excluded a lot of well known ui elements from our design because we decided they were not fitting the Nextcloud design & identity. Simplicity is key here and so far we have gained a lot by moving to this way of working, we have saved a crazy ton of hours :)

Nonetheless, you mentioned you would be happy to help. So I'd be happy to have an in-depth explanation of the areas you think Nextcloud needs to improve and what components do you think we're missing here.
Stay safe!

[0] https://github.com/vuematerial/vue-material/issues/83
[1] https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html

@jancborchardt

Also, which app would it be – @rafenden any preference?

An app that have many various UI elements could make a good example.
Settings, perhaps?

Thank you for your thoughts @skjnldsv, I will try to address all of them.

don't agree with your "the UI feels inconsistent"

Well, let me give you a few examples:

Click to show screenshots

CTAs

image
image
image
image
image
image
image
image
image
image
image

Lists and tables

image
image

Cards (content tiles)

image
image
image
image
image

Form select fields

image
image
image
image

Form errors

image
image

google web is far from implementing their own material ui

They are using material UI, although slightly modified.

Material is incredibly wide


And that’s what we want! :)

All the above inconsistencies could be avoided by implementing a design system with a large library of UI elements to chose from.

Developers were forced to create new UI patterns because there was nothing they could reuse.

We already have our own theme engine

To me, it still seems hard to achieve a fully themed template, in many cases themes need to address styles using CSS IDs, it feels hacky and this won’t work [well] with 3rd party apps.

With Bootstrap, you could simply target all the buttons by the btn class and you could choose from widely available themes.

For that, the design system we'd have to take would have to fill 100% of our needs, otherwise we'd have to modify it.

It’s enough for the design system to provide basic building blocks, the rest could still live in the nextcloud-vue project.

Here’s a brief list of currently missing UI elements (most likely wrong):

  • Form elements and errors
  • Cards
  • Tooltips
  • Grids
  • Pagination
  • Tables
  • SVG Icons
  • Alerts
  • Typography

And last but most important point: Accessibility!

This is a very good point and the Vue implementation of material design doesn’t offer any a11y features, in this case we should consider a different design system like Bootstrap (or anything else TBH).

Maintaining an accessible UI library is hard work and I dare to say that only a part of the current Nextcloud UI is accessible, this is just another good reason to bring in a UI library that does this right.

having a small set of very well written components is the simplest way to go for us

While the direction of nextcloud-vue is good, it’s missing a lot of components.
How long it will take to develop them? Months, years?

Instead, we could spend fraction of that time converting the existing apps to a new design system like Bootstrap.

To summarize, without a doubt, Nextcloud (or any large project) needs a design systems and that’s what we currently don’t have. While nextcloud-vue slightly closes that gap, it’s not a design systems in a true sense.

This move will not only make the UI look more consistent and professional but it's also going to lower the development costs.

While the direction of nextcloud-vue is good, it’s missing a lot of components.
How long it will take to develop them? Months, years?

You're assuming we want as many components as Material design. We do not. I will just quote myself:

We excluded a lot of well known ui elements from our design because we decided they were not fitting the Nextcloud design & identity. Simplicity is key here and so far we have gained a lot by moving to this way of working, we have saved a crazy ton of hours :)

They are using material UI, although slightly modified.

Then it doesn't count. You cannot start using a design system and allow adaptations of it because it doesn't fit your needs. That goes against the principle of it :shrug:

To me, it still seems hard to achieve a fully themed template, in many cases themes need to address styles using CSS IDs , it feels hacky and this won’t work [well] with 3rd party apps.

It's because this is not a proper implementation of a theme as material does it. Material doesn't allow modifications of spacing, passing, shadows... etc etc.
You can change the tint of it, and this is what we do as well. We're far from being done making sure everything is well polished of course, but this is the direction we took (youtube did the same) and we'll continue this way.
Let's not use a custom userstyle as the proper way to illustrate theming ^^


Thanks a lot for all those screenshots!
I see sooo many things to fix indeed :sweat_smile:
Keep in mind though we cannot enforce apps that we do not maintain, you used some of them. :)
You also captured lots of areas that are not using the vue components at all or not to what we recommend (forms, files, settings, the post-it one, vault...) I could do the same with the play store and give you 90% of apps not following material ui ;)
Having a design system is not what ensure that everyone uses it.

Nonetheless, I think you raised a very solid point for me.
We did not created screenshots and mockups of usual areas of an app with the new vue components. That is why there are still some inconsistencies. This and also because we recently decided to update our design a bit which only Talk have implemented so far (this you cannot go against, this is just versioning issues, and even Material struggled making sure the various updates were propagated properly)
@jancborchardt could you maybe help here? I think we should really list all the areas we consider as standards in apps and link them to their respective components/standards. If not implemented yet, we'll have a list of what we're missing :tada:

And last but most important point: Accessibility!

This is a very good point and the Vue implementation of material design doesn’t offer any a11y features, in this case we should consider a different design system like Bootstrap (or anything else TBH).

Not even bootstrap seems to be doing it properly.
And I agree with you, this is hard work, but that is what we do :)
I'm not duplicating my work by relying on an external design system that doesn't implement xxx and making sure everything

I dare to say that only a part of the current Nextcloud UI is accessible, this is just another good reason to bring in a UI library that does this right.

Oh yes! Definitely! So many room for improvements ;)
You seems to have forgotten that this takes time though. You should have a look at our legacy code base and cry with us :see_no_evil:

You can take Nextcloud at today's date and make a statement that this is far from being a11y compliant. But you would miss the point. The areas that are migrated to the new vue components are (I wouldn't dare to say fully) compliant to the aria guidelines. (Or in the process of it, but you get the point.)
It doesn't matter what we use, if I have to do some work to migrate legacy code to a new standard, I will either build my own or use a all-in-one package. There is none, so I'm not duplicating my work by migrating to material/bootstrap and implementing a11y on top of it.

This is a slow process but after seeing how far we came from and more importantly, the benefits of what we did over the last year, I have no doubts we took a right direction (notice I didn't say THE right direction, a problem often have multiple solutions to it, choosing also means to give up!)

You can change the tint of it, and this is what we do as well.

An example theme would be dark mode, not a custom logo or primary colour which currently could be changed by the “Theming” app.

Keep in mind though we cannot enforce apps that we do not maintain

Yes, you can’t enforce app creators but you can encourage them by providing a good selection of tools to chose from.

Not even bootstrap seems to be doing it properly.

and

so I'm not duplicating my work by migrating to material/bootstrap and implementing a11y on top of it.

IMO, Vue implementation of Bootstrap is doing pretty good job in the space of a11y.

And I agree with you, this is hard work, but that is what we do :)

Isn’t better to spend more time on new features and not reinventing the wheel?

This is a slow process

Creating something alone is a slow process, but getting help from existing frameworks will make the process smother for core and 3rd party developers.

I truly believe that:

This Is the Way — The Mandalorian

I think that at least for lower level building blocks it would make sense to take a closer look at this

so I'm not duplicating my work by migrating to material/bootstrap and implementing a11y on top of it.

IMO, Vue implementation of Bootstrap is doing pretty good job in the space of a11y.

Oups, sorry about this one, you're right!
I looked the bootstrap docs, not the vue-bootstrap. My apologies :)

And I agree with you, this is hard work, but that is what we do :)

Isn’t better to spend more time on new features and not reinventing the wheel?

That's one of the oldest developer question :)

I'll stop now, because I think we covered what we wanted to say, and it seems we just have different visions on the use of external libs (and those long texts are exhausting :hot_face: )
So thanks again for sharing it, it took quite some time, but even if I still don't fully agree, we at least are on the same page towards unifying the UI and making sure we have nice components that ease up the development :)
And that is all that matters! :hugs:
Stay safe!

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings