Ember Between Design and Development
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 37 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/34697 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 201628 / 37
4
5
7
10
11
13
14
15
16
17
20
23
24
25
26
27
29
30
31
32
00:00
CodeVideoconferencingRoyal NavyCollaborationismSoftware developerError messageInformationMessage passingState of matterGroup actionMessage passingSoftware developerMultiplication signComputing platformProjective planeSocial classWebsiteState of matterData managementCollaborationismMathematicsPhysical systemVideo gameConnectivity (graph theory)MereologyElectronic mailing listProcess (computing)User interfaceTask (computing)Software documentationInformationBoss CorporationControl flowExtension (kinesiology)Product (business)Greatest elementType theoryPartial derivativeRoboticsSign (mathematics)Template (C++)Cartesian coordinate systemMobile appPattern languageExpressionGreen's functionCodeDependent and independent variablesTupleLatent heatComputer fileFluid staticsIterationFocus (optics)Roundness (object)Element (mathematics)Goodness of fitLoop (music)Electronic program guideWritingNP-hardRoutingLogicVisualization (computer graphics)Graph coloring2 (number)MultiplicationXMLComputer animation
08:08
Software developerWeb pageConnectivity (graph theory)ConsistencyFeedbackCross-site scriptingRandelemente-MethodeBlock (periodic table)Element (mathematics)Data structureData modelCodeWeb browserSoftware testingSynchronizationEuclidean vectorSocial classInheritance (object-oriented programming)Price indexElectronic program guideSocial classBitUser interfaceWeb browserConnectivity (graph theory)Cartesian coordinate systemMultiplication signProjective planeDecision theoryTelecommunicationWeb pageEvent horizonSoftware documentationCategory of beingAxiom of choiceSoftware developerBlock (periodic table)Object (grammar)CodeTerm (mathematics)Arithmetic meanTwitterConsistencyType theoryStandard deviationSoftware testingService (economics)2 (number)Parameter (computer programming)Data modelGraph (mathematics)Group actionFigurate numberMedical imagingSource codeNumbering schemeTemplate (C++)Revision controlDescriptive statisticsGraph coloringAdditionCuboidNamespaceComplementarityEndliche ModelltheorieSynchronizationAreaWebsiteSheaf (mathematics)MathematicsProcess (computing)Mobile appDifferent (Kate Ryan album)Element (mathematics)Java appletAttribute grammarOnline helpLatent heatWhiteboardDemosceneAcoustic shadowComputer fileComputer animation
16:05
Element (mathematics)Electronic program guideConfiguration spaceCloud computingCross-site scriptingPartial derivativeClique-widthData structureInformationShared memoryFunction (mathematics)Link (knot theory)Euclidean vectorElectronic data interchangeData typeElectronic program guideProjective planeLatent heatMultiplication signGroup actionDifferent (Kate Ryan album)CodeSocial classLink (knot theory)Element (mathematics)FeedbackConnectivity (graph theory)RoutingMobile appAttribute grammarSoftware documentationDescriptive statisticsComputer fileCore dumpVariable (mathematics)Module (mathematics)CASE <Informatik>Sheaf (mathematics)Form (programming)Data structureElectronic mailing listGraph coloringCorrespondence (mathematics)Markup languageInformationType theoryTemplate (C++)Software developerPartial derivativeConsistencyoutputReal numberFlow separationComputer fontDirection (geometry)Random matrixComputer iconCuboidConfiguration spaceFile formatMereologyDataflowParameter (computer programming)QuicksortSoftware testingWebsiteDisk read-and-write headArithmetic meanStandard deviationLine (geometry)Integrated development environmentGamma functionCartesian coordinate systemPattern languageComputer animation
24:02
Correlation and dependenceAuthorizationBuildingSynchronizationElectronic program guideMobile appCASE <Informatik>Position operatorConnectivity (graph theory)System administratorClient (computing)CodeRoutingMathematicsBlock (periodic table)Multiplication signLimit (category theory)Point (geometry)Software frameworkSoftware developerMaxima and minimaDemo (music)Graph coloringCentralizer and normalizerUser interfaceBitProcess (computing)Server (computing)Online helpSign (mathematics)outputFunction (mathematics)WordPerfect groupProjective planeElement (mathematics)Embedded systemGroup actionOntologyExtension (kinesiology)MultilaterationSynchronizationRight angleWaveEncapsulation (object-oriented programming)Network topologyComputer fontDiagramVideo gameBeta functionPlastikkartePower (physics)Computer animation
Transcript: English(auto-generated)
00:19
I hope you can hear me fine. I have just a normal microphone because I forgot about pockets.
00:24
So, yeah, welcome to our talk about Ember between design and development. My name is Lisa and I'm a user interface designer. And my passion is like visual design in general, but I also love to bring to life my designs with HTML and CSS.
00:42
This is Francesco. He's my coworker and our JavaScript developer. And he really loves to write clean and efficient code. But even more than this, he loves to create apps which users really can and want to use. So, usually we are from Austria, from the lovely city of Innsbruck, but currently we are on an extended business trip in America to get to know our customers
01:04
and to conduct some user research. So we are working for the company Cropster. It is a relatively small company which is based in Austria in Sacramento, and we create all tools for coffee traders and farmers, but especially coffee roasters.
01:21
So, just recently we launched a new Ember best product which is called Cropster Hub. It is an online green coffee trading platform and also an auctioning platform and is totally made out of Ember. And we are also recently redoing our whole inventory management system for coffee with Ember.
01:42
So, why are we holding this talk today? We have been now working together over three years on multiple Ember apps. And we've just come to realize how important it is that you have a good collaboration between the often-posing groups of designers and developers. We have learned that you can save so much time on existing projects,
02:05
but also on new projects when you have really good collaboration and documentation. So, we want to show you today why collaboration is so important, why designers should be able to code, and why developers should be able to understand design.
02:22
How documentation can you help within your collaboration process, and which documentation we use in our Ember apps, which is the code documentation, a living style guide, and a component guide. Hi. So, first of all, why is collaboration so important? Well, think about the engineering of a car.
02:42
So, Max designs a nice vehicle body for a city car. It's nice and green, and he's very happy with it. At the same time, Ann develops tires, which are perfect for rough roads. She also put a lot of work into it, and she's equally happy with the outcome. But when the time comes and they put those parts together, it doesn't work at all.
03:04
So, both did a good job on their own, but they just didn't have the same understanding of the new car. They didn't collaborate well enough. So, how can we apply this to our own industry? Many companies have had a workflow like this for a long time.
03:21
So, the designer creates a Photoshop design. Let's say site design.psd hands it to the developer, who then implements it with HTML, CSS, and JavaScript. And many companies have been quite successful with this approach. So, why should you care to mix it up?
03:40
Well, in reality, the workflow doesn't stop here. So, there will be the time when the designer needs to do a few changes to the design. So, they might create a second Photoshop file, site design-final.psd, hand it to the developer, who has to go through the file, find the changes, and implement them in code.
04:00
But then, there will be another round of changes, and another, and another, and another round of changes. In the end, everyone wasted a lot of time, because the designer had to go through the developer for every little change, and everyone will be unhappy. So, this might have been a bit exaggerated, but I'm pretty sure many of you have experienced something close to this before.
04:23
So, let's imagine a better workflow. This better workflow might still start out with the designer creating a static design with Photoshop. But then, the designer also writes the basic HTML templates, and the CSS, and hands all of this over to the developer,
04:41
who then implements the static HTML templates with handlebars, I'm talking about Ember, and writes the JavaScript logic for it. And when the time comes, and they have to do some adaptions, they can work on it together. So, it's really just a static design that is the sole responsibility of the designer,
05:02
and the JavaScript app code that is the sole responsibility of the developer. Everything else is shared. All iterations are made in code. The designer can do especially smaller changes on their own, without bothering the developers, and everyone is happy.
05:20
So, of course we know that this kind of workflow requires designers, and I cloned myself, to write valid and meaningful HTML and CSS. But we think that this is really important, because when you're able to write valid and meaningful HTML and CSS as designer, it is not that easily possible
05:43
that you create a design which is really hard or impossible to implement. So, regarding Ember apps, we of course also propose that the designer is able to write handlebar templates. And yes and no, when you start to code as designer, you sometimes feel not that confident about it, but in reality, when you have a basic understanding of HTML,
06:07
learning handlebars is not that hard. I don't say that you have to create components by yourself on the routes. It's great when you can do it. But to start out for a designer, it's just like you have to go into it and just try to don't mess things up.
06:22
The developer already made it work. So, when you go in here and as designer, I want to change something in the styling of the info message, I just have to know where to put an additional class. I just have to know that I put the additional class not within the if expression. Or another example where you see this unordered list
06:40
and with the each loop, the list elements get generated. So, I as designer just have to know when I want to change something, I just do it within the each loop so I don't break something. So, the most important thing about that is don't try to be afraid. Just try it out and believe me, the developer is really happy to help you out when you don't know something.
07:03
So, I know sometimes in some projects, it's not possible that the designer can also do the whole HTML CSS code or the handlebars template. But still, it is really important that design specifications are really clear. So, let's just take a simple example.
07:20
Let's just take a button. Designers, and yes, I include myself, sometimes complain about, you know, the developers, they are not able to implement my design in a way I wanted it to be. But have you ever thought about that designers do not deliver the designs in a way a developer can really work with it?
07:40
So, let's say the button. You get a static Photoshop file as developer. You will just implement it that way. But has the designer also thought about what happens in between those two states? So, it would be a good beginning if the designer hand this over and says something like, you know, the button should have a transition between all those states. Because an application, of course,
08:01
is a dynamic application. It would be even better if the designer hand this over and says something like, you know, the button should have a transition on the background color and the box shadow with our standard transition time, which is 0.3 seconds, and then ease an in-out transition. And it would be the best if you could just hand over the SDSS for that.
08:23
So, as long as we're not able to read minds, it is really important that designers deliver design specifications in a way a developer can work with it. So, while we do believe that designers can be expected to know a bit about HTML and CSS, we shouldn't forget
08:41
the flip side of this. We also strongly believe that we developers can be expected to care about design, to analyze it beyond the obvious and to care about its execution. So, of course, I do not expect developers to become the designers. I know that I could never actually design an application.
09:02
But I do think that we can do better than we often do. So, when we receive a design from a designer, don't just try to recreate it one-to-one. Ask yourself, does the design actually make any sense? And is it consistent to other pages
09:21
or components you implemented before? So, chances are, the designer did a conscious decision in deviating from another component they designed before. But maybe they just overlooked something. It happens. We're all human beings. So, talk to the designer. In my experience,
09:40
no designer I've worked with so far has had a problem with explaining their choices to me if I talk to them in a constructive and nice way. So, don't go to the designer and say, hey, this looks really bad or it doesn't work at all. Try to give a concrete example of what the problem is and maybe even a possible solution for a problem.
10:02
Another thing I want to add is that many developers don't care that much about CSS. But CSS is not that trivial. So, I don't know how many of you have felt something like this when writing CSS. I know that I have felt like this a lot of times. So, CSS is not that trivial, but CSS quality
10:21
is important. So, there are many developers who would spend hours trying to optimize a JavaScript class. But it would then be quick to just throw in a couple of inline styles on a button. Because why not? It works. But it doesn't really work. When the time comes and you have to make changes to the UI and the time will come, then this will be very hard to maintain.
10:42
So, don't use inline styles and use some kind of consistent naming scheme for your CSS. So, for this purpose, in our project we use BEM, which is short for Block Element Modifier. I don't want to go into this in any detail. You don't need to use BEM. You can use another naming convention. You can come up with your own naming convention.
11:01
It doesn't really matter. Just have a naming convention and get everyone in your team on board to actually using it. The last thing I want to mention is that the data model does not equal the user interface. So, we developers should not build an application in a way that makes sense to us. We should build an application in a way
11:21
that makes sense to the user. And just because we might use terms like items in the app code, it doesn't mean that we should also use these terms in the user interface. So, now, as we have complained enough about designers and developers, we want to talk about how documentation can help you to establish an
11:41
integrated workflow and the shared vocabulary. So, why should you care about documentation at all? The first thing is it's all about consistency. Once users know what a specific UI element does in your application, they expect the same UI element to do the exact same thing over and over again. And if the UI element
12:01
doesn't do that, the user gets frustrated. And that's bad. So, another thing is you get really faster and it's easier to do cross-browser testing because when you have like a style guide or a component guide, you can just use that guide in any browser or on any device and test the UI elements. You don't have to go from page to page and test everything.
12:22
And when you have something like a centralized hub for your documentation, everyone can go to and you have a faster workflow. Chris mentioned it yesterday in his talk about living style guides. He said it's really easy that you get new developers or new designers
12:40
to help them onboarding. And that's really true. So, everyone in your team gets faster. You now might think, okay, that all sounds very good, but how can I do some kind of documentation in my company? So, the most important thing you should remember from this talk is when you do documentation and yes, you should do it,
13:01
you should do it always like integrated in your project. What does that mean? It means your documentation should be always 100% in sync with your code base so that you don't stop doing it. But thanks to Amber CLI, this is relatively easy. So, the first piece of documentation we use is code documentation. So, I'm
13:22
guessing or I'm hoping that most or all of you use some kind of code documentation in your projects. So, what we want to add there is that we also feel it's very helpful to have a standalone human readable code documentation outside of your source code commands. So, for this purpose,
13:40
we use UiDoc, which you might have heard of. Basically, it creates a nice documentation from Java doc style commands in your app. So, this is what this looks like for one of our projects. We've made our own scene for it which is pretty easy to do. So, on the left pane, you see all the
14:00
classes we have. We can select one class and then you see all the details on the right pane. If this appears somewhat familiar to you, that's probably because the AmberJS API docs also use UiDoc. So, it works very well with Amber apps. It's not tied at all to Amber. You can use it with any JavaScript-based project. There is an add-on, Amber CLI
14:20
UiDoc, which you can use or you can just use the standalone Node version for this. It's pretty easy to use. You just add commands like this on top of your JavaScript files. So, we just put there a very short description of what the file does. If it's a component, we like to add a short code snippet of how you would use this component
14:41
and then we just define a namespace, which would be the object type, like component, service, etc. Then the class name and what it extends from. Then in the class, we just document all the different things in there. So, we would document attributes with at attribute and the type.
15:02
We would document methods with at method. You can specify parameters for methods and return values and actions, we document them with at event, which is nice because events can also take parameters and they show up nicely in a different section in the generated documentation.
15:22
So, the really nice thing about this is that it's not only useful for developers. It can also be used by designers. So, for example, if a designer is working with a handlebars template, they can use this documentation to find out which properties are available on a model or on a component to actually use in the
15:41
template. And while most designers will probably not feel comfortable diving into the app source code to find out which properties are available, going to this documentation and looking it up there is pretty straightforward. So, let's talk about the Living Style Guide. Chris had to
16:01
talk about the Living Style Guide yesterday. We used it a little bit different. For us, the Living Style Guide is a documentation of our CSS classes, how they will look like and how you can use them. So, basically it's called Living because it is auto-generated from our CSS as CSS or less. It depends what you use.
16:22
So, why are we doing the Living Style Guide at all? As mentioned before, consistency is really important. And you only realize how important consistency is if you look at inconsistent examples. So, when I started with redesigning one of our older applications, I started out with a so-called UI inventory.
16:43
That means you go into an existing application, look for a specific UI element and make just a screenshot of it. And every time you see the UI element which does the exact same thing, you just make another screenshot. So, that's what I found when I looked just for a normal button with the same action on it.
17:01
So, as you can see, we have a lot of different button stylings here, but like behind it, every one of those buttons does exactly the same thing. Why does this happen? This happens because a lot of people are working on the same project but without a shared style guide. So,
17:20
the next step I do when I create a new application or redesign an existing one, I create just a design sheet. So, basically it is an outline in which the design direction goes. It includes like a color theme, the basic UI elements, some icons and some other things. But it's really simple. And then I take this design sheet and go to the
17:41
developer and to the project owner and talk about it. They give me some feedback on it. I iterate over it. And then the next step is that I directly implement all those basic UI elements in our living style guide. So, how do we do that? We use in our Amber projects Broccoli Living Style Guide.
18:02
We use that add-on because it is especially made for SES. And we use SES, so SCSS in our project. Then we make some basic configurations there. For example, like how the style guide should look like and how the code formatting within the style guide should be. And then I can just start create SES partials and corresponding
18:22
markdown files with the same name. And then I can serve our living style guide with Amber-Surf and every time when we change something in one of our markdown files or in one of our SES partials, the whole style guide gets reloaded. So we make sure that the style guide, so basically Amber, makes sure
18:40
that our style guide is always up to date. Then you can just start styling. So when everything is set up, I create my first SCSS partial, which is usually something like button SCSS. And I put all the main CSS in it. I always then style just the plain tag as well, because you
19:00
should keep it as easy as simple as possible. But I also add on another class like dot button when I want to have a link look like a button. And I also put all other modifier classes in it. For example, button secondary, which just changes the color of the button. When I'm finished with that,
19:20
I just add a corresponding markdown file, which is called underscore button MD, which has just all the HTML markup in it and some description if I want it to be. And then everything gets reloaded and automatically built. And the outcome, as you can see, is like you see all UI elements
19:42
and HTML markup. And you can just go in and copy and paste the stuff. So this is how our file structure in general looks like. We have this core folder, where we put all our core styles in, which means those are things which we change from project to project, like variables or our
20:02
theme or our layout. And then we have a lot of files in our modules. Those are things we've learned we can use from project to project and are very similar. So like, for example, like basic box stylings or chart stylings or whatever. They just depend on some variables, but we change the variables from project to project.
20:22
And then we also use like, we put also some of our styles directly in our component folders so we can use the Amber components from one project to another. And another thing we realized while we do a lot of Amber projects.
20:41
Oh, wait. This is how actually this style guide looks like. So when it is rendered, you can see we also build it in our documentation app. We added on a navigation so you can jump from one part to another. You can see which color variables we use, how you can use input forms,
21:01
how our buttons will look like, and the cool thing is those are like really the real UI elements so you can just try it out, hover over them, like get a feeling how they will look like in the real app. So, and as we work on several Amber projects, we found out that all, some of our Amber projects
21:21
have the same styling. So we decided to make a shared add-on. This shared add-on contains all our general styling informations. And then all our other Amber projects just use this add-on. So how do we do that in our workflow? We just set the is developing add-on to return true in
21:40
our add-ons index.js file and then we create a local copy of our add-on in our Amber project and run this project with Amber serve so every time when we change something in our add-ons CSS also our project, our other Amber project we work on gets reloaded which is like really helpful during
22:00
development. So the final piece of documentation we use is the component guide which sits somewhere in between the living style guide and the code documentation. So Chris in his talk yesterday about living style guide what he calls living style guide is what we call a component guide basically
22:20
so it shows Amber components in action how they look like, how they can be used. So it's aimed at anyone that works with templates so in our case both designers and developers and such is important to not become too tacky when describing stuff so it's only really important
22:40
what a component does and not how it does something. This is what this looks like in our project so this would be the section for form elements for example we have a C button component and you can see I hope you can see there is a list of attributes with a type and a short description
23:00
that you can use for this component then you actually see the component and the code snippet which shows how you can use the component. So right now we don't use any special tools for this this is basically a route in an Amber app with the component in it and the description but we might switch to Amber Freestyle now after
23:20
Chris talked yesterday, it was really impressive and nice. So the way we did it now is that we created a very simple component that doesn't do anything fancy, the only thing it does is make sure that we have a somewhat unified layout for our component guide. So we
23:40
put a lot of those in our component guide route for basically every one of our components. So on top you would just define how the component is named then we would define all the attributes that this component can take with a name and a type and a description.
24:01
Then, and this is actually the most important part, we would include the live component. So you might think that you could just go ahead and copy paste the HTML output of your component from somewhere in your app and put it in here. But that is not a very good idea because it will get outdated when you change something in your component. So really try
24:22
to include your actual components in here. If you're having trouble doing this, that's probably a sign that your components are too tightly coupled to something else, which is something you should avoid anyhow. So actually building a component guide like this is also a good way to find out if you build your components in a
24:41
reusable and encapsulated way. And then finally we have a code block which is basically the same as the demo block, just escape the component so it is not rendered and then we add some syntax highlighting to it. So on smaller projects we
25:01
basically add a route or a collection of routes just in our app where we put this component guide on. This works very well and it's pretty easy to do. However, it has the disadvantage that this will also be served with your app if you deploy it, which is something you might not want. So this is something you need to handle
25:21
in this case. So what we do is only locked in administrators which is us basically can access these routes once we deployed it. For bigger projects, Lisa mentioned it before, we have a couple of internal embed ons that we use where we have all our styling but also all our
25:41
reusable components that we use in multiple apps. So basically most of our components are in multiple add-ons. So we have a separate standalone documentation embed which also includes all these add-ons and this documentation embed app is our component guide. So
26:01
this is completely separate from our user facing apps so it can never be deployed by accident. We have set it up in a way that whenever one of the add-ons changes and we push it to Git, our build server will rebuild the documentation app, put it onto our internal server so everyone in the team can
26:21
look at it and it's always up to date which is super helpful. We also put the living style guide in this documentation app and UI documentation so this is our central hub of documentation for all our Embark projects which works really well for us. So if you take something out of this talk
26:42
it should really be try to understand your teammates. This could only work if you really sit together open-minded and if the developers try to get a little bit involved in the design process and the designers try to get involved in the development process and if we find
27:00
together a way which works for everyone. And the most important thing you should remember here is when you do documentation and again, you should do documentation keep it always 100% in sync with your code base because when you decide to do a standalone documentation app, trust me there's a time when you just
27:20
stop doing it because you just have no time or you just forget about it. And the last point I want to mention is always try to be better. Try to reiterate about your workflow and improve it. So even after this talk we'll probably go home and improve our workflow we have hundreds of ideas collected here.
27:42
So I would love to come back to the example from the beginning. Just imagine if Max the designer of the vehicle body would have been sitting together with Ann in the beginning and if they would have sketched out a framework in which the car should work. Just let's say a city, the outcome would have been a completely different car.
28:02
It would have been a perfect one. Thank you. So the question was how much time we spend on keeping it up to date the Style Guide?
28:21
So it's not too bad if you start doing it from the beginning. It's probably pretty hard if you try to tack it on later. So as Lisa mentioned we basically start coding in the Style Guide and then we do changes in the Style Guide and then we look
28:41
in the app how they look there. Something like this. So we always do all the changes in the Style Guide first more or less. So that's not really an issue for us. So it's like I just can give a quick example. Like last week one of our developers asked me, he needed an input with a dynamic label because we just added an input where you can
29:01
put like a dollar sign or something but not like a whole word. And he said he would need one with a dynamic label so what we did we just like improved the existing one in our Style Guide and then like he used this one for all other things. So we always want to have like the one perfect UI component and we just really do it right in our Style Guides. So
29:20
it's not that much work.
29:42
I can just like unselect the first step. I come from the client side so before I worked just like as a freelancer and I did a lot of design projects and I have to say like I switched over to like creating a design sheet first and just like implementing right now in the Style Guide. So not always with Ember of course but I did it before
30:02
just like standalone Style Guides with KSS for example and the outcome was pretty cool because sometimes when you're like a designer you discuss about things which are like not that important like the color of the green or like something, a positioning of something which is not that important and when you start out just with a design sheet
30:20
and then like directly implement it within a Style Guide, there is no such discussion about like how exactly you put things. You can really focus on improving your UI elements. So actually I think it works pretty good in an agency wise as well. Another thing I want to add here is that this will a thing like this will probably
30:41
it will be worth it a year from now basically. So when a year from now the client comes back and wants to do some changes and maybe there are new developers who will work on this project who haven't worked on it before so they have basically no idea what you did now. If they have something like a Style Guide they can go there and work
31:01
from there. If they don't have something like this it's basically do whatever you think is best and this is something you can really help with when you have a Style Guide. I just can say as a designer in general when you want to be a user interface designer you have to be able to code. It's not a limitation
31:21
it's like an extension of your skills. It's just an example I gave in the beginning. When I make a user interface I really have to think about animations and transitions and not only like the static buttons so I think you have to learn code.
31:46
Thank you.