I find them somewhat connected so best UX practices. Well, it’s a it’s a list of things, a list of principles and practices compiled by miss Heidi under Nick, and you can find the list at the above-mentioned address. So if you haven’t seen this document, this is what I’m going to talk about on the lecture to some extent, I find this applicable also to desktop applications and the development of software in general, so they are actually quite useful things.
The mobile first approach, an approach in which you can use those best UX practices to produce better software and, finally, at the end, I’m going to talk about responsive design, so a combination or an application of these two. So if you want to follow the best UX practices – and you want to do development mobile first, then most likely you are going to need responsive design, let’s start with those timeless rules for creating intuitive web apps.
As I said, this is not only for web apps. This is for computer applications in general. First, we have something called, don’t reinvent patterns. You know, users have their habits, they have been using their computers for quite a while. Usually you shouldn’t contradict with your application, their intended behavior, and if you make a confirmation button in red, then that’s clearly not right, because most people associate red with error and usually in at least in the Western culture, where you read from left to right.
The button that takes you to the next page is actually, on the like right hand, side in the bottom and, if place it somewhere else, this might be a source of a confusion to the user. What you get by applying this or by not reinventing patterns? Well, you get a lower learning curve, which is always good, so your users can start using your software right from the beginning without having to learn any particular things, and you have the principle of least astonishment, so this is also.
In other words, this is the don’t reinvent the patterns things. Grouping related elements is another good practice, so whenever you have stuff that is related to each other, it makes sense for it to be like in the same place or just in a very close place and inviting you can use shared styles for that. So if you can’t place them directly next to each other, you can at least clean them to make them look related in general, your users should be able to guess what a particular part of your software does by just you know looking at stuff around that part, Then we have the principal called less is better.
This is I divided it in two things. One is on the UI level, where you try to limit distractions and focus on what is relevant. The other part of less is better is the functionality, and this is something that I hope you will all apply in your projects. So do one thing well focus on the bare necessities of your software, and if there is time left then just add more, but do not try to you know, put everything in one place and hope that it will magically work.
It won’t start with one thing: make it perfect and then add new stuff. An example. Is Linux shuttles, so this is, like you know, a shell tool. Just does one thing well and if you want to have some extra stuff, then you have to put them together. There is a common input/output next tip is to plan before developing. This means that you should well, as it says here, design interaction before implementing, which means you should spend some time before.
You actually sit and start coding on planning and laying out how your application is going to look like and again. You should focus on essentials, two things on how to achieve that. One is to get a second pair of eyes, which means that you should find somebody who is not a software developer to take a look at your wireframes and you know user stories and tell you what can be improved. I said it many times throughout this lecture software developers, design, crappy, UI and the other tool that is going to help you in in planning.
The stuff is the the user stories. If you are somewhat familiar with agile, then you might heard about user stories. So these are small documents that you write and they always go AUSA and then roll I want to, and then you explain the things that you want to do with your software. This is actually very helpful because once you get your essential user story, so the one that describes what you want your software to do, then you can, you know, build wireframes for that so plan.
What screens the user sees on the way from the very beginning, to the very very end of that action, then you can get a second pair of eyes, so somebody to look at those make some improvements, and once this is done, then you can actually start implementing It providing feedback is very important in any software. That means that you should acknowledge users actions, so if the user has done something, you should make the user aware of the fact that something happens.
This usually requires a very little effort, but it greatly improves user experience. Like the overall user experience of the software you’re developing unobtrusive help having help without actually stuffing it in the users face that usually works. You should assume that your users know how to use your software, except when they don’t, and then you should indicate that there is help that they might want to read, but they don’t necessarily have to.
Of course, they can still stare at the login screen for 10 minutes if they wish so and next step is to help users decide this kind of follows the principle of least astonishment that I was talking about previously about not making anything that the users wouldn’t expect. If there is a few pages process that the users are going through, make sure that they know what is the next button to press or any next thing to do.
Please make sure that whatever patterns of styling and theming, you use, they are consistent across your software. So there is really nothing more annoying that the fact that in one subpart of your software, the process of going through something is done with a wizard that you press next buttons and then in the next one. You have one page that you have checked you scroll up and down now this isn’t going to work.
If you’re developing software, you typically have a target group in mind, so a set of people that you know they are going to use your applications. They have certain qualities, they are, you know you can define it as a group. You should assume some common knowledge. So if you’re developing software for engineers, then you can assume they likely know mathematics and if you have some complex mathematical terms.
Well, you don’t have to explain them because well it’s for engineers, they should know it. This helps in focusing on the functionality and removing destructions. Well, you assume certain things that the people will know. You don’t have to pollute your UI with extra explanations of those things. Helping users realize where they are so what part of the system they are in? How did they get there? There are two bullet points.
One is clearly marking the progress and the other one is allowing navigation back and forth, especially the navigation back and forth is something that is often forgotten in web applications written with Vardon, because everything is just running on one page without any state to preserve from different Steps, for example – and this is where we can use navigator a rule of thumb – is that you have changed the state of your application that you should change the URL of it.
So then, by just entering the URL, you can come back to the place. You were previously, you can bookmark that place. You should make good use of some navigation parameters so inviting you can have a view name as the first part of the URL address, and then some parameters and it’s up to you. What is the syntax of those parameters where did that come from, and this is basically meaning to show transitions between elements? A good example here is a buddy notification.
Actually, it’s not jumping at you from the middle of a screen. It transitions from a corner, or you know there is an animation that shows it so you’re not surprised that you’ve actually seen the notification. It’s it’s always nice to use this sort of applications. You know with animations and fading out and Sony kind of gives this Pleasant feeling about okay. Well, this is nicely thought. Then we have designed for no data.
I’ve marked here that this is a surprisingly good rule, and it really is. I have been developing software for quite a while already, and this is like the first time I’ve actually seen it written somewhere when the users start your software, what data they have none and in most cases it’s just an empty screen, because you haven’t thought about putting There something you always assume that there is data, because, while you’re developing the software well, you clearly have the test data to work with well, the first time users they don’t.
You have only one chance to make the first impression that actually applies not only to software development. You know, but when your users install your software and start it, then they shouldn’t see an empty screen. They should see something, for example in IntelliJ. If you close. All of those, then you don’t see a blank screen. You see some help once you get used to this software. Will you just ignore this text, but if you’re, the first time user? Well, you at least see some pointers, and this is connected also to dis.
Unobtrusive help next part is to be consistent. Your UI, your major structure of the application, should be more or less the same throughout the entire software, regardless of the part you’re at and inviting we can do it with navigator. So navigator requires a viewport, a part where you can display the stuff that changes from one view to another. Well, this is already what you want, so you have some parts of the system that are consistent regardless of the view, and then you have a part that changes from one view to another.
This is purely related to web applications. You should load the content quickly. There are some studies, I really haven’t memorized the numbers, but the users are very impatient if they have to wait longer than some two seconds or something like that. There are some practices that you should load most of the stuff in the first X kilobytes of the response, so by principle you shouldn’t: let users wait if they click a button, and there is an operation that takes a really long time.
Well, you should indicate that it’s really happening so that something some feedback has been given to the user like they know what to expect and if they really have to wait at a particular screen. Then we’ll make sure that there is some information for for that, and it can be also fun. I don’t know how many of you have played Sim City for this. You know it’s a city building game and in in the version number four.
If you create a new city or a new landscape which takes a really long time to load, then the loading messages are actually funny kind of a related topic to that is progressive web applications. So this is a new trend in mobile application development, a rule about testing. Well, this shouldn’t be a rule, but then, on the other hand, it should ideally, your software should be tested by somebody who hasn’t developed it, who hasn’t designed it and who hasn’t like used.
It at all – and it should be a member of target group – many things that that you should take into consideration. The reasoning for that is twofold. As I said, you know how your software works, so you will obviously not make any mistakes that lead to an error or throwing up some nasty exception, and the other one is that the developers are crappy UX designers. Your users might have completely different expectations from how the software should work or look than you and it’s natural.
You should you shouldn’t be angry at them. You should appreciate that they tell you this it’s better. They tell you, while you’re developing the software, then after you’re developed and deployed it because then they’ll just find something else in your place, inviting we can do it with test bench. This is a Pro Tools, so it’s a paid feature of Warren. It’s basically a j-unit code that runs your software, you can click buttons enter text into various places and it will check if it really works.
It’s really good for acceptance and regression tests. That was that was it that summarizes the good practices of UX development. I think, or at least to me when I was when I was reading those I found them very useful – it’s nice that it’s just 14 points. They are not that very hard to remember and not that very hard to follow and the resulting software will have well at least some quality to it. If you try to follow all of those.
No, let’s talk about a mobile-first approach. Let’s come back to our shoutbox application and how was the UI planned from the very beginning? I had a clear idea that I want to have a text at the top and the bottom there on the right and then the content on the bottom filling up. The rest of the screen – it looks quite okay on the monitor like in here and that’s because desktop monitors are horizontal.
Most often they have more pixels from left to right and from top to bottom, did I ever resize the browser window while developing or showing did. I even think about it. That’s that’s actually a good question. I’ve never thought about that. Why are these questions important? That’s because software developers they use computers, other people like people not being software developers, they don’t use much of computers.
For example. When was the last time your mother used a computer to process web assuming she’s, not a software developer, because I know some mothers are software developers. Modern phones are always connected to the Internet like they are always there, and most of the people have internet in their pocket, and this is how most people, not being software developers or mothers of software developers, how they connect to the internet, how they bro stuff.
It’s the phone, it’s not the computer anymore, and many people do not even need a computer, because everything you will ever need is probably available as an application form. The important thing is: what’s the shape of a mobile device screen? Well, it’s also rectangular, but not horizontal anymore. It’s vertical! It’s a bit different. There are two approaches for developing or targeting software for mobile platforms.
The first one that was there at the beginning is called graceful degradation and graceful degradation means that you start with a fully blown up and it’s optimized for desktop. Where there is huge screen. There is lots of processing power, all the bells and whistles they can be. There it’s desktop app and then, as you scale to smaller devices, you start removing things, but still you try to keep the functionality as it is, so your software really has to work.
But now you know the screen is smaller. There is less space to put all the elements around. That’s why it’s called graceful degradation. The opposite of that is progressive enhancement, and this is where you start with a fully blown up, but it’s optimized for mobile. You have a very small screen. You have a slow, CPU and well basically, no extras. The trick is to add features. As the screen gets bigger.
You still keep the functionality as it was, but now you have extra space, so you can add. I don’t know more information, more fine tuned buttons more. What Evers to the application as it was – and this also connects to the first or one of the first rules, that you should focus on functionality. You should keep it simple if you’d start with one thing and do it well and then, if you have some extra screen available, then you can just put extra things there.
Why progressive enhancement is good. As I said, you start focusing on a very small scale. It’s minimal requirements, essentials only and maximum functionality. This is going to be used on a mobile phone. It has to be simple and functioning portability of that solution is also good. I mean it’s not a problem if you have too much of screen space and if you add it extra, why is it bad? Because everything comes at the price right? The biggest drawback is that you have challenges and constraints right from the start.
You can’t put everything on a screen and hope that people will still see it. That means there is more work on the planning stage already, so you should be prepared to have a stripped down version of your idea, because your idea about your application is most likely concerning a desktop browser, not a mobile browser. There are different behavioral patterns, so there is typically on a mobile device.
Users do not mind that they have to tap the screen or scroll it down. Well, then they scroll up and down and not left right now it must work instantly, and you know this is a mobile device. People are connected, it has to work really fast, otherwise they just shove the phone in the pocket and just go so overall. Is it not that bad? No, it’s it’s not it’s slightly more difficult, but you should apply it by default.
Well, you shouldn’t apply it if your application is never going to be used by a mobile user. Well, sorry, this will never happen, and this is because currently about 25 percent of the Internet users are using only a mobile device. Of course you shouldn’t blindly follow it. You should apply it where it makes sense. Not everything has to be mobile-friendly. Then again, not everything has to be a web application, so you can, just you know, stick to desktop applications and the last part of today’s lecture is the responsive design.
These are the like UX practices that were told first and then the mobile-first approach – and this is responsive, so how you can connect these two. It’s a web design technique where you rearrange the contents of the page. According to the display size, it means context-aware elements. So the elements themselves that you see in the HTML code, they kind of know what is the screen dimension, whether they are visible or not? What role do they play, how they are colored? This is quite an advanced approach.
I have to say because it’s another level of complexity, so not only you have to figure out how your mobile screen should look like and how your like desktop screen should look like, but also how do you transition from one to another if you’re using responsive design? It gives awesome results, one UI, regardless of the platform, it’s just the styles that are different and the whole code, the whole logic of building the UI binding it to events.
Everything stays regardless of whether the users use use mobile or a desktop, and it’s also good because it preserves the information here. Are he if there is more space, you just add extra stuff and what is shown on the small screen is the top essentials of whatever. Should be displayed there in valen, we do it with responsive, responsive is an extension to a component, and you can make any component responsive you just for responsive, not make responsive and then a bunch of components most likely.
You are going to use it on a layout and, like 99 % of the case, it’s going to be a CSS layout. That’s because, as you all remember, from the lecture, CSS layout delegates, all the layouting to the browser and to the CSS file, what you should remember, though, is to add a style name for that CSS layout, so that you can refer to it from a CSS file. What you get is that you can use responsive a CSS syntax, so you can specify with range or a height range of your component and adjust the stuff accordingly in here the upper bound doesn’t have to be present, so you can make it from.
I don’t know. 100 pixels up and so on, and the range is that you define they may overlap, and all of those that are matching they are active. There is one terms and conditions’ applies. All resources must be in the same domain, so unfortunately, no referee of anything outside your application, how we can use it in practice. Let’s make our shout box a bit more responsive. I couldn’t actually come up with anything, so I thought that for small screens we’re going to remove the room navigation like completely and we move the text field in the button to the bottom of a screen not to the top of the screen.
I currently haven’t yet figured out how I flip the order of labels so that the most recent ones show on the bottom. That’s why I didn’t mention it here. The top level layout will be responsive, so I’m going to show you some code. Our change is that I just added a few style names and when it it must have been added before. But this is the key part, so I’m making responsive the main layout and I’m going to make sure that it’s called shout box.
So I can refer to it and there is nothing else that has changed so just this and and some styles, but then there are a few things in the CSS file. Since we have started with a desktop up, then we were cutting down parts as we as the display shrinks when the width range is less than 1000 and 100 pixels, then, which is not displaying the rooms and the caption and we’re also not displaying the caption on The top, and then we move the entry bar to the bottom.
That’s it uh-huh there we are, so you can see that there is a caption here. There is a rooms here, and this whole thing is is on the top. Now, let’s resize the window, whoops I’d kind of resized itself, a bit outside of the screen come back here now you see it it’s different. Now this is on the bottom and as we resize this once we reach thousand and 100 pixels, then it will flip back to the previous okay.
Hopefully, oh yeah, there you have it written on the top and us ask the users have smaller space than this flips back and nothing except the style has changed, and it’s still the same UI file that it was there previously and now we have the power of Responsive layouts in our app that’s it. Today we went to the principles of web application development. As I said, these are not only valid for web applications.
They are valid for any software that interacts with with people a mobile-first approach. For me, it requires still some mindset. Change but I think it’s it’s a good practice, at least to consider the mobile users. I mean you can’t fight this, that people will use mobile phones and then the responsive design. There were just two slides about it, but that’s really it I mean there is nothing! No extra magic involved and you just make a layout, responsive and a new code CSS for it.
That’s it that’s how it works.