As an interaction designer looking for better ways to collaborate with developers, I have tried to introduce Pattern Lab to my current client. The lead developer for the front end framework pushes back, however. Main gist of his argument:
Our toolkit has complex components that require JavaScript or a JS library in addition to HTML/CSS. This would not mix well with the Mustache or Handlebars templating in the Pattern Lab. Thus we use Angular JS, which is the framework that our components are written in.
I have tried to look for articles that discuss this topic. There's nothing here on SO as far as I can tell. Outside SO I have found just a few posts (example), but nothing that's specifically on the topic of Pattern Lab's (lack of) compatibility with Angular, except for a parsing issue that was solved two years ago.
As a non programmer I don't have the necessary influence to sway my developer peers. Would be great if someone with hands on experience could elaborate.
Reusable patterns created with Pattern Lab are IN NO WAY dependant on Mustache, so your developers can rest assured that pattern Lab does not introduce any dependencies that will carry over to their code.
In fact, the whole point of a style guide, built using Pattern Lab or not, is to build a language independent library of style patterns -- HTML markup and CSS -- which developers can reuse in their apps, whether they choose to build them in AngularJS, ReactJS, Plain old server-side code behind or something else.
Pattern lab is just a convenient tool for the front end developer or designer who maintains the style guide. It generates a static style guide website showcasing the different patterns. That website will be the tool for project developers using the patterns. Just as AngularJS can be used in any static site, it can of course also be used in a static site generated using Pattern Lab.
Mustache is part of the tool stack Pattern Lab uses to generate the static website, but no traces of Mustache or dependencies upon it carry over to the resulting website. I serve several AngularJS teams with design patterns hosted on Pattern Lab, and none of them have ever had to touch or even know about Mustache.
If your developers are familiar with frontend frameworks like Bootstrap or Foundation, which offer documented patterns for different front end blocks, this is just the same. Developers on different projects can copy HTML markup and CSS code without any other dependencies.
A style guide should be a prerequisite in any modern web development setup, as it's a prerequisite for smart and efficient collaboration between developers and designers and makes quick prototyping much quicker. So I think the discussion you should be having is whether you should use a style guide to collaborate and aid more efficient collaboration. If you come to an agreement around that, Pattern Lab is just a smart choice for developing one.
Here's a good intro to using style guides, and also to different toolsets you can use to build one. Pattern Lab is listed under the section for Style guide platforms:
https://www.smashingmagazine.com/2015/04/an-in-depth-overview-of-living-style-guide-tools/
Hopefully this can spark a better discussion with your developers, they're missing out if they stop you building a style guide.
Maintainer of Pattern Lab Node here.
I just created this reductive sample repository illustrating Angular within Pattern Lab.
Repository https://github.com/bmuenzenmeyer/patternlab-node-angular-example
Live Demo http://www.brianmuenzenmeyer.com/patternlab-node-angular-example/public/index.html
As you can see, Pattern Lab can run arbitary frontend code, including Javascript, within the confines of a single pattern, so a motivated individual could showcase components using it.
That said, I don't think that PL's "with the grain" approach of building atomic components works perfectly with Angular (like, don't build your whole app in here) but showcasing the JS behind, say, a tooltip or modal component, is possible in isolation.
This strategy would be similar to reminds me of https://rizzo.lonelyplanet.com/styleguide/design-elements/ - in which they have UI components alongside JS components.
Hope this helps clear up any confusion.
We have successfully built Pattern Lab into our development workflow. We simply adjusted the patternlab build to copy the resulting CSS files into the assets folder of our application. Developers write all CSS and templates in Pattern Lab and the generated files are automatically used in the app.
Related
I would like advice on how best to move my company toward using VMWare's Clarity system, or something very much like it. Should we use it as a template? Fork it? Integrate parts of it over time?
By Q4 of 2018 we would like to:
have a decent Design System
develop in Angular 2
use Bootstrap 4
Currently we are here:
No Design System
Bootstrap 3.3.7
AngularJS
Any suggestions will be helpful!
The Clarity Design System is composed of several parts.
There are Design resources - sketch templates for the light and dark themed components as well as documentation and guidelines for using them. In addition, we publish three packages
#clr/icons - an icons library that can be used standalone. The icons are web-components and can be used like any other element in a project after you integrate it into the app
#clr/ui - standalone html/css for clarity themed components. For obvious reasons more advanced components like the datagrid or wizard are not part of this
#clr/angular - Clarity components for Angular applications.
To answer a few of your questions.
Q. Should we use it as a template?
A. No, Clarity (#clr/angular) should be integrated into your Angular application so you can use the components to build up the application with them.
Q. Fork it?
A. you are welcome to fork the code, its open source software (MIT License). If you want to stay up to date with the latest bug fixes and enhancements though I would suggest integrating it into a project and keeping up with the incremental releases. We generally try to release once a week and callout breaking changes at least two versions with deprecations.
Q. Integrate parts of it over time?
A. I (as a Clarity UI Engineer) would recommend adopting it fully from the beginning when you start your next Angular app. If not, you run the risk of competing design systems and conflicting styles and UX patterns.
We do not recommend using Clarity with Bootstrap 4. Even though our grid is based on an earlier beta version of Bootstrap 4. We would like to remove that as a dependency in the future.
I need to get my Meteor JSapp in more than one language.
What would be the best approach for i18n?
Google passed my quite a bit of results but reading them I am more confused than happy. There a many hacks but is there a settled solution to this?
This is more a comment than an answer (however my repu still is too low :o):
Localization normally is only needed client side (there are exceptions but not many and they can be dealt with) and as Meteor is quite young with an own templating engine it's normal that you find more hacks than stable solutions.
However you can doge that bullet by using an older client side templating technique than Meteors built in one like AngularJS with Angular-Meteor (http://angularjs.meteor.com/). Personally I can just recommend this project as it gives you a lot more power than Blaze alone does. And now when you look for solutions for localizing AngularJS you will find a lot more. One I can recommend is angular-gettext (https://angular-gettext.rocketeer.be/) which also comes with a grunt script to extract and compile your strings in one click and which builts a .pot file so that you can translate your app with PoEdit just like you would with an old school webapplication. The only thing you may need to do yourself is to extend the grunt script to parse for any custom translation functions you may add (but maybe you can live without those than you wouldn't need to do anything).
Here's a situation I run into a lot with CSS architecture using BEM/SMACSS. I'd like to see how other developers handle it.
You have a library of CSS modules that you use across multiple sites. Modules like .btn-group, .nav-tabs, etc.
Then you encounter a module that's styled in a very site-specific way -- it's too unique to be able to use one of your library modules.
So you have the code for that "site module" in a Sass/Less file and you save it with the other style code for that site, like the layout styles. It's not saved with your "library modules."
My question is: do you do anything to distinguish the "site module" from your "library modules"?
I usually follow YAGNI principle in CSS which helps making decisions in these sort of circumstances. Following always implement things when you actually need them, never when you just foresee that you need them approach a new module starts its life as a site module. Whenever I need to use that module in more than one site then that is the moment I consider turning it into a library module.
This issue is solved with the help of Levels of Definition.
The main idea is that you can split blocks (even parts of the same blocks) into different layers which you combine on a project. E.g. you can have library level (or a few of libraries) and a project level or it could be different levels according to environment: common parts for all the platforms and different ones for desktop and tablets and so on.
See http://bem.info/method/filesystem/ for more details.
Has anyone had any luck testing a Flex app without static Automation IDs attached to components? All of the elements in the apps are generated .....
We've investigated FlexMonkey but it appears to be incompatible with any app that utilizes the ExternalInterface. RIATest's scripting language leaves much to be desired...
Thanks-
Jonathan
Unfortunately I don't know much about this kind of stuff, but I went to a talk that presented these tools for TDD:
- Hudson
- Flex Unit 4
I guess there are tutorials online, don't know if it helps with ExternalInterface testing.
Is there anything that prevents you from generating appropriate automationNames for your generated components? This way you should be able to refer to them properly in automation tools.
Are there any other non-changing properties that your generated components have, like maybe 'id'? If so you can use these properties to address the components. This is definitely possible in RIATest.
FunFX is a Flex automation tool that allows you to access components via ID, "automation name", "automation value" or index. While using something like the component index might be less than ideal for robust tests, if that's all that's stable, it might be worth a try. And it's written in Ruby, so that should satisfy any "real programming language" related requirements. :)
We added an "automationPrefix" property to many of our custom controls (particularly those that are reused many times on a single screen), and wrote code to append the beginning of the automationName property on any child controls. Setting the automationName was the most important parting of enabling automation testing on our Flex apps. There are several ways you could modify the automationName to be unique without making it completely static at the level that most test automation packages need it. We are currently using QTP as the test automation tool of choice.
Recently our newest web designer asked me why we use ASP.NET for our website. Reading through his question to the real one, I started thinking about it myself. Why are we using ASP.NET for web development?
The problem we find so far is colaboration between the design team and developers. Typically our designers create some snazzy cool look crayon laced web pages, then show them off for approval in all their glory. Once approved, the developers rip the HTML out and shove it in to ASP master and detail pages, and huzzah! out comes pretty website.
Since Dreamweaver doesn't play nice with Visual Studio, this is the same process for even small tweaks and changes. I would prefer to just write the backend and let the designers draw the pretty pictures and fancy CSS. Our current websites have plenty of reason to use ASP on nearly every page, so I can't do half in HTML, the other half in ASP.
I have no aversion to doing something else, another language, CMS platform, some other random buzzword, etc...
What are your experiences with this design situation? Are we doing it the hard way? Should we consider alternate platforms and languages? Are there any good, proven ways to allow designers to work on ASP (while still using Dreamweaver)?
Start learning Asp.net MVC as soon as possible. Designers will love you for that. :) And you'll be up to date with new development technologies that will also make your solutions much more robust and less complicated.
But otherwise. Designers should be able to read XHTML fluently. Learning asp.net semantics shouldn't be too hard. Then give then Visual Studio where they can manipulate content. As long as they know how asp.net web forms work things should be fine. They'll probably be able to do majority of things using just CSS. I know I can. Sometimes I do have to check resulting HTML, but it works.
Aside from Wicket (a java web framework), I don't know of any framework or language that would allow designers to continue to work on the design once developers have started to add logic to it.
I would suggest two things though:
Use a MVC framework - ASP.NET MVC, Ruby on Rails, Django, etc since this allows for far more separation of presentation and logic
Keep your presentation layer as stupid as possible and use helpers as much as possible or even better, put the logic in the domain objects. The view should only show or get data with absolutely no logic for processing data, this will keep the pages much more designer friendly.
I find your question very interesting because no matter what kind of technology the project uses the interfaces between the different roles will always cause some friction. I am not sure if there is a technological solution to this communication issue because the designer and developer speak literally different languages.
Depending on the skillset of your designers and developers an additional layer might help you out. I do not know how ASPX works but i am sure there will equivalents to the concepts of other technologies.
In case you have mainly static content which can be expressed in XML than you could provide the backend which delivers the content in XML with a defined Schema and your designers could describe the transformation in XHTML and CSS via XSLT. Given that your designer are capable using XHTML and CSS the addtional effort to learn XML and XSLT is not that huge. I find this solution much powerful than template languages which try to emulate the richness of the serverside scripting language in their own limited constructs. In case you have dynamic elements on the clientside like DHTML, AJAX or you name it you could define your own xml tags which are transformed to richer client side objects after the designer did their work. I guess the designer will understand the usage of these special tags and you provide the proper translation into client side objects.
I used this approach with some coworkes based on PHP. PHP was only the driver for the transformation. The content was assembled into xml with special tags which were transformed into XHTML and CSS via XSLT. Once the objects and the transformation for the different objects is defined you build up a library which can help to shorten the developement cycle of new pages of you webapplication. The benefit of the extra work is, that you designer can change the layout of the page without ever touching you server side code.
Maybe this helps.
Consider using either Expression Web or SharePoint Designer. The latter is now free.
I know you specify dreamweaver, but have you looked at Blend? It plays very nice with Visual Studio and is quite a nice app. to work with.