Live data from Hacker News

Clarity Design System for Angular 2

vmware.github.io

41–50 of 51 posts

Re: Clarity Design System for Angular 2

#41
post #40

Earlier quoted context omitted.

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 su…

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.

Re: Clarity Design System for Angular 2

#42
post #40

Earlier quoted context omitted.

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?

Re: Clarity Design System for Angular 2

#44
post #43

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

Re: Clarity Design System for Angular 2

#45
post #42

Earlier quoted context omitted.

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!

Re: Clarity Design System for Angular 2

#46
post #16

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.

Re: Clarity Design System for Angular 2

#47
post #39

Earlier quoted context omitted.

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.

- 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 whe…

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.

Re: Clarity Design System for Angular 2

#48
post #18

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!

Re: Clarity Design System for Angular 2

#49
post #47
post #39

Earlier quoted context omitted.

- 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 whe…

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 belie…

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.

Re: Clarity Design System for Angular 2

#50
post #22
post #18

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?

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/

Post reply on HN