5 ms·

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: h

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 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 https://github.com/vmware/clarity-seed

jonoc 10y ago
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 :)
- jaffoneh 10y ago
  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!
currywurst 10y ago
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-collapsing.html http://mleibman.github.io/SlickGrid/examples/example5-collap...)
- jaffoneh 10y ago
  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 https://github.com/vmware/clarity/issues/67 [1] https://vmware.github.io/clarity/documentation/datagrid https://vmware.github.io/clarity/documentation/datagrid
merb 10y ago
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?
- jaffoneh 10y ago
  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!
- coderageous 10y ago
  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.
wiradikusuma 10y ago
Is it safe to say Clarity is for Angular 2 as what Blueprint (http://blueprintjs.com/ http://blueprintjs.com/) is for ReactJS?
- jaffoneh 10y ago
  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.
  - ceejay 10y ago
    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.
    - jaffoneh 10y ago
      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.
      - ceejay 10y ago
        - 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.
scwoodal 10y ago
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.
- jaffoneh 10y ago
  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/ https://vmware.github.io/clarity/community/
  - scwoodal 10y ago
    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.

jonoc 10y ago

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 :)

jaffoneh 10y ago
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!

currywurst 10y ago

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-collapsing.html http://mleibman.github.io/SlickGrid/examples/example5-collap...)

jaffoneh 10y ago
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 https://github.com/vmware/clarity/issues/67 [1] https://vmware.github.io/clarity/documentation/datagrid https://vmware.github.io/clarity/documentation/datagrid

merb 10y ago

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?

jaffoneh 10y ago
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!
coderageous 10y ago
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.

wiradikusuma 10y ago

Is it safe to say Clarity is for Angular 2 as what Blueprint (http://blueprintjs.com/ http://blueprintjs.com/) is for ReactJS?

jaffoneh 10y ago
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.
- ceejay 10y ago
  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.
  - jaffoneh 10y ago
    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.
    - ceejay 10y ago
      - 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.

scwoodal 10y ago

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.

jaffoneh 10y ago
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/ https://vmware.github.io/clarity/community/
- scwoodal 10y ago
  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.