UI/UX Tips & Tricks for developers
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 | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46869 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2020178 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
Software developerSoftware developerPattern languageContinuum hypothesisTwitterComputer architectureInterface (computing)Computer animation
00:24
Rule of inferenceFundamental theorem of algebraConsistencyPattern languageInterface (computing)Link (knot theory)Slide ruleCore dumpConsistencyArithmetic meanRule of inferenceView (database)Computer animation
01:24
Group actionModal logicWeb 2.0Point (geometry)Line (geometry)Greatest elementGreen's functionGroup actionTerm (mathematics)Physical systemElectronic program guideInterface (computing)WaveShape (magazine)CASE <Informatik>Software developerBitMachine codeRight anglePosition operatorWeb pagePattern languageTouchscreenGraph coloringContext awarenessConnected spaceDivisorRule of inferenceContrast (vision)Order (biology)Arithmetic meanError messageReading (process)Flow separationType theoryInformationOperating systemNegative numberPort scannerDescriptive statisticsClique-widthComputer animation
06:40
Group actionGame controllerGraph coloringConsistencyGroup actionInterface (computing)Reading (process)Task (computing)InformationComputer animation
07:28
Link (knot theory)NP-hardCurvatureDistanceSimilarity (geometry)1 (number)Axiom of choiceAttribute grammarGraph coloringShape (magazine)Interface (computing)MathematicsDatabaseObject (grammar)Theory of relativityRevision controlState of matterMultiplication signDecision theoryNumberOrientation (vector space)Group actionPhysical lawLine (geometry)Link (knot theory)EmailComplex (psychology)Axiom of choiceDifferent (Kate Ryan album)SoftwareMultiplicationDirection (geometry)DistanceSimilarity (geometry)Form (programming)1 (number)PixelOrder (biology)Acoustic shadowGradientTwitterUsabilityType theoryWeb pageWeb 2.0LengthGreatest elementBlogCircleCurvatureDataflowPRINCE2Principal idealSource codeExecution unitLie groupComputer animation
13:29
Axiom of choiceRule of inferenceSerial portPosition operatorLocal GroupForm (programming)Field (computer science)NP-hardTable (information)Computer iconRule of inferenceOrder (biology)Form (programming)Field (computer science)Port scannerError messageTable (information)Context awarenessComputer iconCartesian coordinate systemTime zoneoutputInformationPlastikkarteFile formatInterface (computing)Zoom lensMappingMultiplication signNumberDecimalComputer configurationWordSemiconductor memorySound effectSequenceGroup actionElement (mathematics)AverageWebsiteLimit (category theory)Arithmetic meanPoint (geometry)Position operatorCodeAlphabet (computer science)Metropolitan area networkGame controllerMessage passingDigitizingView (database)Line (geometry)Logic gateRow (database)Term (mathematics)Information privacyChainSystem callTheoryLevel (video gaming)Structural loadComputer animation
19:29
Open sourceAxiom of choiceCode refactoringPoint (geometry)View (database)Slide ruleTwitterDivisorComputer animation
19:57
Pattern languageComputer configurationCategory of beingMusical ensembleOpen source2 (number)Source codeView (database)Complete metric spaceSoftware developerWordDemosceneArithmetic meanProjective planeArchaeological field surveyGeneric programmingWebsiteResultantGoodness of fitDomain nameInternet service providerDifferent (Kate Ryan album)Physical lawDefault (computer science)Template (C++)Higgs mechanismService (economics)Type theoryAsynchronous Transfer ModeSimilarity (geometry)Forcing (mathematics)Latent heatMultiplication signComputer animation
24:53
FacebookOpen sourcePoint cloud
Transcript: English(auto-generated)
00:05
I think we're good, so I'm going to hand over to Kati, who's got a great talk about tips and tricks of design for developers. Lower the bar, please. Okay, so hi, my name is Kati Namoraru, you can find me on Twitter at Válika.
00:22
I don't know if you've been to Amit's talk, he talked about patterns in architecture, but similar to architecture, we also have patterns for interface design, and I provided a link there, the slides are available on Twitter, so you can go if you're interested in more, because some of you asked about patterns,
00:42
but in this talk we're going to go even lower, so even at the core principle. So there will be the basics, so patterns are more advanced, maybe we can talk about that in the future, but now we'll go even lower. So principles are fundamental rules, and if you were to apply just one principle in your day-to-day interfaces,
01:07
that would be consistency. So what consistency means, if the user learns your interface once, he will know how to use it in subsequent usages, and that is very important because it's much faster for him to react.
01:24
But if we're saying that we're designing a consistent interface, this doesn't mean that all the buttons need to be the same, there are several types of buttons, and it's very important to have a primary action on your screen,
01:40
so the user needs to know what is the main thing you want him to do. And primary actions are usually designed with more contrast and color, so he gets the point on what you want him to do, and they should be like only one per screen.
02:02
And these primary buttons need to be very clear, so we should avoid things like yes or no, or read more, or stuff like that. Users think in actions, they want to delete something, or they want to add or to edit, so we should use verbs. We should not have long buttons,
02:23
I mean we could give context, but verbs are more efficient in terms of directing the action. And also, when we ask the questions, we should avoid double negatives or very abstract things, we should use a common language, and make it very clear what we want them to do.
02:45
There has been a very big debate on where the button should be placed. It should be placed on the left side or on the right side, and if we are developing a native application, it's much more easy, because the operating systems have guidelines and style guides,
03:01
and they have a preference, but if you're designing for the web, on the web the rules are not that strict, so I just want to show you some points of why you should pick one or another. For example, on left align, it's very easy for the user to vertical scan.
03:22
He can read the title, or he can read the labels, and if he finds the button at the end, he can just jump from the title to the action. But if you want the user to actually read the description text, he will make like a Z shape, so he will read the description, and then he will need to press the button. In this case, the position matters,
03:42
because, for example, if you're using left align, he will read the text, he will go to the primary, he will see the secondary, and he will need to go back, so it's a bit longer to react, like a millisecond or something, but can add up, at least compared to the other right align.
04:02
Now, it also matters if you're designing for large interfaces or small interfaces. If you're doing a mobile application, it doesn't really matter if it's on the left side or on the right side, because the width is very tight. There are some interfaces that even put the buttons in the middle,
04:22
or the buttons are for width, but when we are designing for web, and now, as developers, we like to have like 8K monitors, if we can afford them, if you don't have columns, if you are applying a right align layout, the buttons can get separated from the context,
04:42
so the user might feel lost or not see the connection between the actions. So here, again, he will do like an L shape. Now, I've talked about primary and secondary action.
05:00
The thing is that, and regarding patterns, there are some patterns like wizards, where you have multiple steps, and you need to go like next and previous, and if you're designing for someone from Western culture, when we read books, we kind of go from right to left, and we're switching pages, so that's why next buttons feel more natural
05:24
to be placed on the right side, but even when you're placing them, just make sure that the primary action is on the edge. Edges are much more accessible, because they're coming, so don't place the primary action in the middle of the screen.
05:44
So again, you need to decide, do I have wizards in the interface, do I need to place them on the right, but if you place them on the right, place them everywhere. Don't switch the position, depending on what interface pattern you're applying. Okay, buttons and colors in general.
06:03
It's very nice that we can attribute some color meaning to the actions, and again, be very sensitive of your target. In Western cultures, red means danger and errors, but in Asia, red means abundance and luck, etc. So they have reversed the green and red.
06:23
But even if we can give all the cultures, try to limit the palette in order to be more pleasing, and we can convey in other ways things like warnings and infos.
06:40
And why it's important at least to have one color for dangerous action is that if you assure consistency across the interface, and all your buttons are, let's say, gray and blue, when the user will see a red button, he will understand that that is a very important, or it's something with that action.
07:04
And for destructive states, it's really important to ask for confirmation. So if you're doing something that will affect the user, ask him to see if he didn't accidentally press that. And I know it's harder to implement the undo the visual controls, but they could be very helpful for the user to feel in control and safe
07:23
and know that he can come back to that. Okay. And I know we talked a lot about buttons, and we still can't have, but there's another principle which is called affordance.
07:40
And affordance, the metaphor is like when you see a door, and if the door has a circular handle, you might know that you might need to switch the handle. Again, if the door has like a pull, you know that maybe you can pull it or you can push it, and that's why sometimes when the door does the reverse thing of what you're expecting, you might be a bit confused.
08:01
You don't know what's the direction. The same for this principle can be applied to links. So for the people that have been for a long time on the web, when they see something that is blue and that is underlined, they might think that, okay, that's a link, or at least I know that's a link.
08:20
So be very careful when applying blue to headers or things that are not linked. In the past year, the designers wanted to leave the old habits and maybe try to express themselves with colors, so it's okay to have links of other colors according to your color theme,
08:43
but the most affordance based on your prior experience are blue and underlined. Same for buttons. When you see a button, buttons usually have the click state, and you know that you need to be pressed. They have multiple states, so in order to increase usability,
09:02
they should be represented as 3D objects that have some shadows or that have some borders or that have some gradients. The flat trend for the past years have lowered the usability of the things because you don't know if that's just a container or it's actually a button. So ideally, they should have these affordances
09:22
that can help the user know what type of entity is in the page. One of the questions is, okay, when we have an action, what do we use? Do we use buttons or do we use links? And if maybe it's more clear that you should not have buttons
09:43
inside the text because maybe you have some alignment things that the line height will get increased because the buttons don't have the same 12 pixels or 16 pixels. This is not actually the way we should be rational about them. Buttons and links have been created for very specific purposes,
10:02
so you should use buttons when you would like to have an action, so something that changes inside the interface. You're adding an element or you're producing changes on the database or something like that, so actions, while if you're just navigating to other places, you should use links.
10:26
Another principle is the proximity principle. So objects that are closer together are perceived to be related, and this is a strong visual principle that we could use inside the interfaces. So, for example, if you would have a menu,
10:42
if you just put some entries more closely together, people will perceive them as related. But it's very important to actually be related, not just place them because they visually look nicer. And this is an example of how it was used to be done in Gmail for an older version.
11:06
Another related principle is the similarity. So similarity states that object sharing attributes are perceived to be related,
11:20
and we can force that using colors or shape or orientation. So if you would want to try to read this, let's say, per lines, your brains will be harder for your brain because the brain will naturally try to put them in groups.
11:41
And having this similarity and proximity principle in mind, there is an even stronger principle that is called the law of unity, which can override cues from this principle. And actually, the thing is that if we are linking consecutive objects by lines
12:01
or by borders or by background color, we can suggest somehow that they are related. And here is an example. So for example, if you're in an activity stream, if you just separate with lines, people will perceive this as an entry or that could be a logging form. Just a note here is that
12:21
we might be very tempted to use these borders and lines, but the more borders we use, the interface would look more crowded. So in the past years, we've seen a fallback instead of law of unity on the proximity. So the designs are more airy and they're using more white space and they're more relaxed.
12:43
And just rely on the proximity, not just on these cues. Okay, choice paralysis. It's a principle that states that if you give the user lots of choices, they might not know which one is best for them.
13:02
And there's another law, which is called Hick's law, that states that the time to make a decision increases with the number and complexity of choices. And what we can do about this is to try to limit the choices we're offering to the user to clearly mark what are the differences. We can apply this, for example,
13:20
if in our software there are multiple download versions, so we should not represent them all the same. Be very clear. Actually, if we can limit just the two and maybe if there are some advanced things, just put them aside. I know we want to show all the options we have, but it's better for them to get the recommendation
13:40
and know exactly what we should expect them to pick from that. And a similar rule to this is the seven plus ministry rule. So a century ago, Miller did some experiments. I thought you were making pictures,
14:02
so that's why I ignored you for a long time. Okay, so Miller's rule, he was having a lot of people and did research. He was giving them lots of words and tried to see for the short-term and long-term memory how many of those words users remembered.
14:23
And the average at that time was like seven plus minus two words. In theory, designers use this rule to always say that we should never have more items in the menus and all the websites should have this limit. But researchers have redone the research more recently
14:45
and the value changed from four plus minus one. There's no clear conclusion on how many items there should be. The point is to have as few in order to be as easy to be used.
15:02
Okay, and there's a principle that is called serial position effect. If you think, let's say, at the alphabet, you know that it starts with A and ends with a Z, but you don't actually, I mean, maybe you do, but some of us have trouble remembering exactly what's inside the sequence. And this principle can be correlated with chunking.
15:25
So, for example, if you would need to have like nine items in a navigation bar, you could split them in groups of three. And this way, you will have a first and a last for each of the groups and they will be easier to scan and easier to remember.
15:41
And also, they should be correlated, not just placed there. And chunking is actually very useful also for form elements. So, I don't know, if you have a card number, you should chunk them. People, when they are trying to remember their phone number,
16:01
they are usually splitting in sequences of two or three. So, it's much easier for the user to know exactly what information they should enter. And regarding easiness, for example, here is an example with a zip code, but the most classical example is when you enter the card details
16:25
when you do a payment. And if a user sees an input of three digits, he might know that that's the CVS that he needs to take from the back of the card. So, it will be much easier for them to fill the form.
16:41
Here, if you place the labels on top, again, it will help with visual vertical scanning. Highlight and explain the error in the context. Some applications have a generic zone where they place the error message and it's much easier to implement like that or with alerts or with toasts.
17:03
But for the user, it's much more clear exactly where he did the mistakes and also provide a hint of what he should fix. And if we are using some white inputs on something that has a light background,
17:20
like it's here, the user will want to fill in the blanks. So, if he sees something white, he will like to fill it and that's how you can increase maybe some forms that have some optional fields.
17:41
Okay. I've seen a lot of times when we have numbers that they are left aligned or centered and the rule is to have them right aligned because if you have decimals and hundreds, it's much easier to compare from one to another.
18:02
And this exclusively, not exclusively, but it's even more important on tables when you have quantitative data. So, you can then apply them to currency or even to date and make sure that the dates have the same format. So, it's easy to scan months and days.
18:23
And here, I've also used easy to digest the date format because we don't want to see those long formats that we usually see in our interfaces. Icons are very important, but try to remember that icons are not universal.
18:42
People might look at this icon and think that it's a search, but it could also be a zoom because maps used it too or they could think it's a ping-pong paddle and they have been tested in some research on this. So, it depends on your previous knowledge with icons.
19:01
You might understand them differently. But icons help instead of just having the names. The first time you will see them, you will not know what exactly that icon means. But on subsequent uses, you will understand that. That means, I don't know, recent tabs or downloads
19:20
and you will just jump at it recognizing the icons and not needing to read the text. I know I went very fast. And there are two books I can recommend if you want to learn more principles of design and the refactoring is more of tips and tricks from a designer point of view.
19:48
The slides are also on Twitter. So, if you have any questions.
20:11
We have 30 seconds. We have time for a couple of seconds because there's lots of people outside and we need to do the whole turnover. Okay. I have probably a controversial question.
20:23
Yes. I use Sphinx documentation for my open source project. Okay. And so, I'm using the default template. Okay. I'm pretty sure like a lot of people who put some effort on doing it really like the most generic nice template. But I feel something is definitely wrong with it. And as a developer, I cannot say like what's wrong with it
20:41
but I would like to get it fixed somehow because like a big team is using the same template for documentation. Like, could you make any comments? So, in general, open source projects tend to do generic things and things that are scalable and the base for theming. So, this is not necessarily wrong.
21:01
But you can do customizations on top, right? And my suggestion is identify what's the problem. You can do that by asking a designer or actually asking other people what they think is wrong with it because I don't know what is wrong. You can make a pull request and try to fix it or just do a theming for it.
21:20
And theming can be diverse because we all have different purposes. So, it might work, I don't know, for the not dark mode but theming should be supported mostly because there are people that are color blind and ideally, I don't know. Yes?
21:40
Similar down there, if you can project set of patterns in medical industry application, specific type of patterns in games, is there a difference between those categories
22:01
or is just not used because it will create a habit and everyone will use it but then that doesn't raise the risk, the threat of malicious participants exploiting this human habit? So, the question is that there are different patterns for different industries
22:20
and this is kind of hard to respond. The thing is that there are common things that all humans will understand and will perceive even psychological principles. It's very important to know your target. I mean, if your target are children or people under 10 years old, you will apply some patterns
22:40
compared to someone in pharmaceutical industry or I don't know. So, yes, industry come with some patterns but you will not find the website that will list them on domains. On the web, we will have patterns like, I don't know, wizards and how the search results should look like but, yeah.
23:03
I don't know any of them but that would be very interesting to know if they are.
23:25
Yeah. So, like we have the good patterns, there's this other category that are called dark patterns and yes, there are a lot of research and people that are trying to combat this. They're usually taken advantage of in advertising
23:42
and making people sell or buy things that they don't want or book things but that's not ethical and any good designer would not want to apply those patterns. But, yeah, you cannot force somebody to apply them or not but they shouldn't. It's not recommended yet. I've seen that Higgs law being abused so badly.
24:07
The what? Higgs law. Oh, yeah, yeah, okay. Being abused like to sell me service providers like hosting companies but do designers take an ethical standpoint like, oh, I've got four options, I'm going to highlight this.
24:25
So, ideally, you should highlight it because you will have the user but depends on your purposes. I mean, if you know how to manipulate these rules, yes, you can propose something that is not beneficial to the user but this depends on the moral values of the designer.
24:40
So, yeah, I don't know how to answer that. Thank you so much for coming.