Clarity Design System for Angular 2(vmware.github.io)
vmware.github.io
Clarity Design System for Angular 2
https://vmware.github.io/clarity/index.html
50 comments
Hi HN, I lead the Clarity team. Would love to get your opinion and feedback! Clarity is fully open source (we open sourced it this morning). Our repo is here: https://github.com/vmware/clarity. You can also take a look at the Clarity Seed for a quick way to start building Clarity-based applications: https://github.com/vmware/clarity-seed
Is it safe to say Clarity is for Angular 2 as what Blueprint (http://blueprintjs.com/) is for ReactJS?
Hi wiradikusuma, for now maybe but when building Clarity we considered a future where we can have ClarityNG/ClarityReact/etc. However, for now, we're focusing most of our energy on ClarityNG to make sure we can deliver the next set of components to complete the library.
[deleted]
I have no experience with Blueprint, or for that matter Clarity, but I do have relatively extensive experience at this point with Angular Material components (NG1).
From first glance it appears that the form input elements on both of those projects are not going to be nearly as mobile friendly as I've found with Angular Material Design components.
I could very easily be mistaken, but already having a sense of what I feel like I need in order to make a nice mobile experience my first instinct would be to skip even trying out either of them for future mobile projects. That said, they both seem solid for building a standard web app the user will navigate with a mouse and keyboard.
From first glance it appears that the form input elements on both of those projects are not going to be nearly as mobile friendly as I've found with Angular Material Design components.
I could very easily be mistaken, but already having a sense of what I feel like I need in order to make a nice mobile experience my first instinct would be to skip even trying out either of them for future mobile projects. That said, they both seem solid for building a standard web app the user will navigate with a mouse and keyboard.
Hi, ceejay! I'd love to know more about how you arrived to that conclusion. I am asking for a couple of reasons:
1. To get more feedback on the docs if that's how you arrived there. 2. To get more feedback on the system itself (design and code) to see if there are bugs we can fix and issues we can improve.
1. To get more feedback on the docs if that's how you arrived there. 2. To get more feedback on the system itself (design and code) to see if there are bugs we can fix and issues we can improve.
- Having seen enough of how different (and sometimes impossible to fix) it is to develop across even just Android and iOS, I am currently of the opinion that future web UI should be moving toward completely decoupling form fields from the native HTML Form Inputs.
A few examples:
- Alot of people will probably see the fancy animation in Angular Material 'placeholder' on text fields transition into a floating label when it receives focus as not having much functional purpose. On mobile, given space constraints, I feel it's a real innovation, not just sugar.
- Because of the differences (and discrepancies in behavior) between the 'time' input field on both mobile web platforms I went out of my way to build an analog clock face to bring consistency between platforms and more reasonable behavior. Some of it is probably personal preference, but I think having an analog clock face is objectively better from the perspective that you can set time (at least how I designed mine) with 2 taps (and maybe one more to toggle the meridian). Compared to how iOS and Android HTML inputs work natively it may not be much of a difference in the eye of the user, but I think there is a lot of room for improvement in this space.
- "tabbing" behavior between fields on a form are different, and because of a strange design decision on Apple's part, it's impossible to reconcile. There are 2 "tabbing" arrows on the iOS keyboard which send no events to the DOM.
- I could probably go on but hopefully it paints a picture of how difficult it is to create a consistent experience easily across these platforms. Not to mention that I get the feeling the number of mobile browser / web-view options (and thus differences that may or may not be reconcilable) will just continue to grow. By decoupling the UI form input component from the native elements it will bring more consistency to the user. I don't know if Angular Material (or other material design libraries) have a goal currently to decouple from the native elements completely, but they feel like they're the furthest along in this respect.
A few examples:
- Alot of people will probably see the fancy animation in Angular Material 'placeholder' on text fields transition into a floating label when it receives focus as not having much functional purpose. On mobile, given space constraints, I feel it's a real innovation, not just sugar.
- Because of the differences (and discrepancies in behavior) between the 'time' input field on both mobile web platforms I went out of my way to build an analog clock face to bring consistency between platforms and more reasonable behavior. Some of it is probably personal preference, but I think having an analog clock face is objectively better from the perspective that you can set time (at least how I designed mine) with 2 taps (and maybe one more to toggle the meridian). Compared to how iOS and Android HTML inputs work natively it may not be much of a difference in the eye of the user, but I think there is a lot of room for improvement in this space.
- "tabbing" behavior between fields on a form are different, and because of a strange design decision on Apple's part, it's impossible to reconcile. There are 2 "tabbing" arrows on the iOS keyboard which send no events to the DOM.
- I could probably go on but hopefully it paints a picture of how difficult it is to create a consistent experience easily across these platforms. Not to mention that I get the feeling the number of mobile browser / web-view options (and thus differences that may or may not be reconcilable) will just continue to grow. By decoupling the UI form input component from the native elements it will bring more consistency to the user. I don't know if Angular Material (or other material design libraries) have a goal currently to decouple from the native elements completely, but they feel like they're the furthest along in this respect.
Thank you for your explanation, it actually brings up several points we didn't know about.
That said, one of the main reasons to use native form controls is accessibility, which is one of our biggest priorities. Maintaining accessibility with non-semantic elements is feasible, but we would end up with bugs fully breaking it, as opposed to a slightly worse UX on some mobile devices.
More importantly, we strongly believe that aiming for the exact same experience across all possible screen sizes is a mistake. If you are trying to write an application that feels natural on both desktops and mobiles, you will need to design two different interfaces, different patterns and probably different amounts of data displayed at once. Your time input example is very relevant: on desktops, you have easy access to a keyboard and a mouse, but sliding UI elements can be a drag. On phones, keyboards are painful to use, but swiping with your finger is extremely natural. Sticking to the native interface (or a customization of the native interface) in both cases will lead to an apparently "inconsistent" behavior, but a user experience that's more enjoyable on both sides.
This is the choice we have made after quite a bit of research, and you can see it for instance on our responsive navigation patterns: we support 3 levels of navigation across the app on desktops, but we limit to 2 on mobiles.
That said, one of the main reasons to use native form controls is accessibility, which is one of our biggest priorities. Maintaining accessibility with non-semantic elements is feasible, but we would end up with bugs fully breaking it, as opposed to a slightly worse UX on some mobile devices.
More importantly, we strongly believe that aiming for the exact same experience across all possible screen sizes is a mistake. If you are trying to write an application that feels natural on both desktops and mobiles, you will need to design two different interfaces, different patterns and probably different amounts of data displayed at once. Your time input example is very relevant: on desktops, you have easy access to a keyboard and a mouse, but sliding UI elements can be a drag. On phones, keyboards are painful to use, but swiping with your finger is extremely natural. Sticking to the native interface (or a customization of the native interface) in both cases will lead to an apparently "inconsistent" behavior, but a user experience that's more enjoyable on both sides.
This is the choice we have made after quite a bit of research, and you can see it for instance on our responsive navigation patterns: we support 3 levels of navigation across the app on desktops, but we limit to 2 on mobiles.
Thanks for the feedback. I agree accessibility is an important priority. I generally allow for fallback to a native element in a user preference option if there's any question about that. Especially with custom components. I've always had to lean on ARIA, which I believe Angular Material components are compliant. As far as I know, since projects I work on generally don't have resources to employ specialists in accessibility. I am interested in this space, though, and would love to start seeing more individuals online blogging / sharing their experience with the current state of accessibility on the web so smaller teams can also learn to accommodate them in a more precise way. I agree it would probably be a major pain point to have to re-design the wheel. I'm hopeful the "componentization" of the web will help here. Apple and Google probably have little incentive to distill their platforms to normalize the development experience, so I see decoupling the components almost as the only way web developers will be able to overcome these things.
I agree with the point about designing different experiences across screen sizes also. It definitely has to be considered on a case-by-case basis, but I've seen some interesting design choices which significantly reduce this pain point. I've almost convinced myself at this point that almost all cases (app types) can be handled by some clever flexbox manipulation and some reasonable media query break points.
I agree with the point about designing different experiences across screen sizes also. It definitely has to be considered on a case-by-case basis, but I've seen some interesting design choices which significantly reduce this pain point. I've almost convinced myself at this point that almost all cases (app types) can be handled by some clever flexbox manipulation and some reasonable media query break points.
Great work and kudos to the Clarity team!
This seems to be a great option for ng2 projects considering the NG2 Material Design is currently in alpha, whereas this looks more "ready-to-go". To my more Bootstrap familiar mind, I feel like I "get" it much faster than some Material Design examples I've seen.
Do you guys have plans for a Tree component ? Would be great if it was and extension to the DataGrid (something like SlickGrid: http://mleibman.github.io/SlickGrid/examples/example5-collap...)
This seems to be a great option for ng2 projects considering the NG2 Material Design is currently in alpha, whereas this looks more "ready-to-go". To my more Bootstrap familiar mind, I feel like I "get" it much faster than some Material Design examples I've seen.
Do you guys have plans for a Tree component ? Would be great if it was and extension to the DataGrid (something like SlickGrid: http://mleibman.github.io/SlickGrid/examples/example5-collap...)
A tree component is definitely on the roadmap. If you have specific cases in mind, we'd love to discuss further in the GitHub issue filed [0] but if what you're looking for is a generic tree component, that's coming pretty soon!
I wanted to make sure you saw the Datagrid component [1] we have. We just published it so please feel free to provide us with feedback and/or raise any issues!
[0] https://github.com/vmware/clarity/issues/67 [1] https://vmware.github.io/clarity/documentation/datagrid
I wanted to make sure you saw the Datagrid component [1] we have. We just published it so please feel free to provide us with feedback and/or raise any issues!
[0] https://github.com/vmware/clarity/issues/67 [1] https://vmware.github.io/clarity/documentation/datagrid
Even if you are VMWare with thousands of developers, do you really think that you can keep up with the speed of development from Angular?
Hi merb, could you elaborate a little more on why you think it is a challenge to keep up with the speed of development from Angular?
I am not sure if there is confusion here but those components are built on top of Angular 2. We use and love Angular 2. In fact, we talk and work with the Angular team and both Angular and Clarity are open source projects. We contributed and would like to continue to contribute back to Angular as well!
I am not sure if there is confusion here but those components are built on top of Angular 2. We use and love Angular 2. In fact, we talk and work with the Angular team and both Angular and Clarity are open source projects. We contributed and would like to continue to contribute back to Angular as well!
hi, i work with the Clarity team as well (Scott M.)
regarding keeping pace with the Angular team, one thing worth noting is that we were up-to-date with Angular 2 Final within two days after its release.
i think we're good on that.
regarding keeping pace with the Angular team, one thing worth noting is that we were up-to-date with Angular 2 Final within two days after its release.
i think we're good on that.
Looks very nice. I've hated angular material docs due to the overly complex examples. These are simple and to the point. I'm keen to try this out for my next a2 project :)
Glad you like it! If you go through the docs as you start on your project and have feedback (either on the docs themselves or on the components/design system) please feel free to either reach out or file an issue on GitHub!
Can you speak about the long term VMware strategy of this project regarding on-going development? Part of my team's decision making process to use open source projects like this (nice work btw) is to get a feel if the primary contributors are in it for the long haul.
Hi scwoodal, absolutely.
Before deciding to open source, we thought really hard about the long term strategy for Clarity. We did not want to open source the project and not be able to continue to build it. One of the many reasons we felt confident this is going to happen is that in the past year, we've build a very strong Clarity community internally. Over 35 product teams within VMware use Clarity and many more are on the way (many of them have not released yet but they depend on Clarity as a Design System for their future).
The team you see on the community page [0] of Clarity is a 100% dedicated to making Clarity successful. This will become more apparent in the next days and weeks as we continue to push more work into Clarity and continue to have more releases of it!
[0] https://vmware.github.io/clarity/community/
Before deciding to open source, we thought really hard about the long term strategy for Clarity. We did not want to open source the project and not be able to continue to build it. One of the many reasons we felt confident this is going to happen is that in the past year, we've build a very strong Clarity community internally. Over 35 product teams within VMware use Clarity and many more are on the way (many of them have not released yet but they depend on Clarity as a Design System for their future).
The team you see on the community page [0] of Clarity is a 100% dedicated to making Clarity successful. This will become more apparent in the next days and weeks as we continue to push more work into Clarity and continue to have more releases of it!
[0] https://vmware.github.io/clarity/community/
Thank you for the quick reply. It sounds like the type of project we could use some day. I appreciate your work and kudos to the Clarity team on the release.
Hi Clarity team,
What would you say the primary motivation in switching from material2 or ng2-bootstrap to clarity would be? At my work we have an Angular 2 app still in development and have been rather dissatisfied with the available component libraries so far. We're at a point where it wouldn't be unreasonable to switch UI frameworks.
Additionally it looks like you have only implemented some of the material design spec. What was the reason for this / why not go full material?
What would you say the primary motivation in switching from material2 or ng2-bootstrap to clarity would be? At my work we have an Angular 2 app still in development and have been rather dissatisfied with the available component libraries so far. We're at a point where it wouldn't be unreasonable to switch UI frameworks.
Additionally it looks like you have only implemented some of the material design spec. What was the reason for this / why not go full material?
Hi water42, I think material2 and other frameworks are fine frameworks and are worth your consideration.
We really built Clarity because we were in your position. No framework out there was able to provide us with what we needed to ship high quality, enterprise software but with modern and consumer-like UIs. We needed that framework to care deeply about user experience (not just provide code) and we wanted to make sure that framework is flexible enough that teams across the company (before we open sourced) can have the ability to understand it, build on top of it, etc.
We really looked around and every time we found something it had a part of the puzzle but not really enough of a part that we can depend on it.
Clarity does not depend on material (the design language), we are definitely inspired by material and others but we're building an end to end design system which includes the user experience and visual language aspects. Behind the components and patterns is a ton of research that we've doing throughout the past few months (and sometimes years depending on the data we have) and want to continue to do. One of our goals is to also share that research in case you can reach different conclusions so the community is able to keep us moving in the right direction.
We really built Clarity because we were in your position. No framework out there was able to provide us with what we needed to ship high quality, enterprise software but with modern and consumer-like UIs. We needed that framework to care deeply about user experience (not just provide code) and we wanted to make sure that framework is flexible enough that teams across the company (before we open sourced) can have the ability to understand it, build on top of it, etc.
We really looked around and every time we found something it had a part of the puzzle but not really enough of a part that we can depend on it.
Clarity does not depend on material (the design language), we are definitely inspired by material and others but we're building an end to end design system which includes the user experience and visual language aspects. Behind the components and patterns is a ton of research that we've doing throughout the past few months (and sometimes years depending on the data we have) and want to continue to do. One of our goals is to also share that research in case you can reach different conclusions so the community is able to keep us moving in the right direction.
Thanks for the quick reply!
It would definitely be useful to publish the research behind the design choices you've made. As a developer with not a lot of design experience that's something I would be interested in.
It would definitely be useful to publish the research behind the design choices you've made. As a developer with not a lot of design experience that's something I would be interested in.
Yeah, we definitely feel that and want to address that use case. Some of that research is shared today in places like patterns and for every components (if you scroll enough in the page) but more research is coming in the next few days/weeks. We want you (as a developer) to be able to not just use the code but if you'd like, be able to fully understand the UX guidelines behind building a Clarity applications and go a step further by explaining why given the research/assumptions we have.
motion seems to be missing, which is a core principle in Material Design! e.g. "ripple"
That is a good observation. This is something we don't have today but we're working on.
I think sharing your repo is excellent, plus, you have adopted angular 2 early and put it out there which is also good.
Be interesting to hear your feelings about Angular 2.
Did u use typescript for this also?
Thanks, we're excited! We started using Angular 2 early this year for Clarity (it was at one of the betas). We should probably write a longer blog post around that (around the journey itself as well as adoption across VMware when Clarity was private), might be useful to others!
As for TypeScript, yes we mainly use TypeScript!
As for TypeScript, yes we mainly use TypeScript!
This is a very nice looking set of controls with a lot of functionality. Thank you to the Clarity team for the contribution to the community. I've got a project in the works that has been screaming for something other than vanilla bootstrap :)
Thanks! Please let us know if we can help in anyway and if you have the time, we'd love to listen to feedback on both: the design system itself as well as the tools you used to use it. As a quick note, we've also open sourced Clarity-seed alongside Clarity to make it easier to get apps up and running on Clarity: https://github.com/vmware/clarity-seed so that might be worth a look too!
Great work! I like Material but this looks super slick and it feels like the documentation is more understandable. The design is really clean. I will consider this heavily when we upgrade our current ng1 app. Well done.
Awesome. Glad you like it. Make sure to share feedback with us as you go through that. We'd love to continue to improve the system itself as well as the documentation!
I'm not able to use it with angular-cli, could you enhance your instalation steps for the current angular-cli?
Hi Mokwa, thanks for your feedback. We shied away from recommending angular-cli in the very early stages, but now that it's become more stable, I see that it would be valuable to add that in our documentation. We'll be working on it very soon. I filed an issue for it on Github if you are interested in subscribing to it: https://github.com/vmware/clarity/issues/79.
Disclaimer: I am on the ng-bootstrap team
The demo website loads very slow :( .
I would recommend looking at https://ng-bootstrap.github.io/ for some code design of some of these components - as far as I can gather looking at the source code of Clarity, it appears to not be AoT-compliant, a big thing going forward with Angular due to the immense perf benefits it brings, and opens up the gate for also being able to use Web Workers/Service Workers.
The demo website loads very slow :( .
I would recommend looking at https://ng-bootstrap.github.io/ for some code design of some of these components - as far as I can gather looking at the source code of Clarity, it appears to not be AoT-compliant, a big thing going forward with Angular due to the immense perf benefits it brings, and opens up the gate for also being able to use Web Workers/Service Workers.
Hi Bahamut, welcome! we'd love to chat with you guys (feel free to reach out to me with a DM on twitter). We'd love to share what we learned and learn from what you learned!
As for the slowness of the page, this is GitHub. It is currently down :(
As for AOT, that's definitely a priority for us (we were talking about it as a team yesterday and are working hard to make it a possibility for Clarity so we're definitely on the same page there).
As for the slowness of the page, this is GitHub. It is currently down :(
As for AOT, that's definitely a priority for us (we were talking about it as a team yesterday and are working hard to make it a possibility for Clarity so we're definitely on the same page there).
ng core team here, feel free to reach out to me on twitter if you need any help getting this done - @robwormald
hey robwormald, will definitely do. We will actually reach out sometime today/this week!
Thanks for the feedback, Bahamut.
AoT-compliance is something we're looking into. Definitely on the sooner end of our roadmap.
AoT-compliance is something we're looking into. Definitely on the sooner end of our roadmap.
As a system designed for "designers" with guidelines, I expected something like Material Design from Google. However, I am very disappointed, even the website UX is very designer unfriendly IMHO. I cannot see a download link or a direction for it in the home page for the mentioned Sketch file.
Hi bertan,
First, thanks for the feedback. Really appreciate you taking the time to provide it. We've actually looked at Material and other visual languages/design systems out there as we do this. We learn from those that started this before us and will continue to do so.
One of the things we think is unique about Clarity is our attempt to get an end to end design system built by a single team of UX and UI engineers working side by side. This includes the UX guidelines (both generic patterns as well as design guidelines for each component), as well as the HTML/CSS/Angular2 components. As for downloading the sketch template for example, that is a pretty good point, I created an issue on github for us to track this and take a look [0].
Just in case you're still looking for it, a link to the Sketch template is available from get started and documentation. I am also adding it here to make it easier to find [1]
We're really looking forward to hear more feedback in order to continue improving Clarity.
[0] https://github.com/vmware/clarity/issues/68 [1] https://vmware.github.io/clarity/images/sketchTemplates/Clar...
First, thanks for the feedback. Really appreciate you taking the time to provide it. We've actually looked at Material and other visual languages/design systems out there as we do this. We learn from those that started this before us and will continue to do so.
One of the things we think is unique about Clarity is our attempt to get an end to end design system built by a single team of UX and UI engineers working side by side. This includes the UX guidelines (both generic patterns as well as design guidelines for each component), as well as the HTML/CSS/Angular2 components. As for downloading the sketch template for example, that is a pretty good point, I created an issue on github for us to track this and take a look [0].
Just in case you're still looking for it, a link to the Sketch template is available from get started and documentation. I am also adding it here to make it easier to find [1]
We're really looking forward to hear more feedback in order to continue improving Clarity.
[0] https://github.com/vmware/clarity/issues/68 [1] https://vmware.github.io/clarity/images/sketchTemplates/Clar...
Looks good, but comparing to other systems like this one but for React, it looks it's relying on plain HTML structure to compose layouts vs. using components system to generate and encapsulate HTML. From what I know Angular 2 supports components so I wonder why is this not leveraged here?
I think what might be happening is a small confusion between our deliverables. Some teams we worked with wanted to use as much of Clarity as possible but couldn't switch to Angular in the short term, so we made sure we could deliver "Clarity UI" and "Clarity NG" separately.
Clarity UI is pure CSS: you just include it on your page, use the correct markup and classes and our styles will be applied. Kind of like using Bootstrap without their JS (most of us have done this).
Clarity NG depends on Clarity UI for styling, but provides full-blown Angular 2 components with the correct markup in their templates, two-way binding, ... That's the easiest way to use Clarity, but it forces you to use Angular.
Unfortunately, our documentation doesn't split the two yet, it starts with the pure HTML/CSS version and then showcases the Angular 2 components after that. Probably explains the confusion.
I hope this helped!
Clarity UI is pure CSS: you just include it on your page, use the correct markup and classes and our styles will be applied. Kind of like using Bootstrap without their JS (most of us have done this).
Clarity NG depends on Clarity UI for styling, but provides full-blown Angular 2 components with the correct markup in their templates, two-way binding, ... That's the easiest way to use Clarity, but it forces you to use Angular.
Unfortunately, our documentation doesn't split the two yet, it starts with the pure HTML/CSS version and then showcases the Angular 2 components after that. Probably explains the confusion.
I hope this helped!
> Unfortunately, our documentation doesn't split the two yet, it starts with the pure HTML/CSS version and then showcases the Angular 2 components after that. Probably explains the confusion.
That's where the confusion come from, thanks for explanation!
That's where the confusion come from, thanks for explanation!
what do you mean by this? you can create a component for any one of their html/css components with custom functionality and "plain html" (it's not really plain since it has two way data binding), then use and reuse that component like any other
I meant that you have to create those components - they don't come with the library itself, contrary to [1] Blueprint for example.
[1] http://blueprintjs.com/
[1] http://blueprintjs.com/
Looks very nice. I am super keen to look at this for a project I am about to kick off.
Am I blind or is there no date-picker? That's the only reason I'm looking for an alternative to angular2-material.
Hi choward, you are not blind! :) We're working on a date picker. If you have specific requirements (especially around localization) we'd love to hear it to make sure we consider it but it is in the works1
Looks nice, might just try it in my next project!