Categories
Online Marketing

Web Accessibility: A Catalyst to Greatness #a11yMTL

So what we’re here to talk about today is A catalyst to greatness and accessibility. So, first of all, I want to start out with a little visual description. For those of you who can’t see I’m female and I’m wearing a shirt with Braille across the front across the chest And the translation of the Braille is If you can read this you’re too close [ laughter, ], Yeah yeah, So just a little visual description there.

So what we’re going to talk about is how you Can be great in usability user experience how you can be great in mobile design, how You can be great in innovation on the web. There’s a key to this and That key is accessibility, So we’re going to talk about how accessibility, Contributes to greatness in all these areas. Accessibility is really about user experience. It’s about adaptability, it’s about flexibility and we’re going to talk about That but, first of all a story Back in 1999, which seemed ages ago.

Now some of us started a small company And it was a usability company. We designed the website with A focus on accessibility, so it had to be highly accessible. We didn’t even think about accessing This website on a phone back, then We didn’t think about it, But then the founder of the company. She got one Of those new fangled phones that you can look at a web page on a screen, A little screen, okay, This is a big deal back then.

So, what’s the first website, she Went to look at on her new phone, Our company’s website It worked beautifully. This was before anyone knew Anything about website design, but just the fact that we had Designed it to be highly accessible and we’d, followed some basic accessibility, Principles meant that it was adaptable and flexible enough to be used on This rudimentary mobile browser, and that’s just because of accessibility, So a lot of what we do even today, For accessibility directly relates to what we need to do for mobile design, So a little bit more history.

How many of you have heard Of progressive enhancement, Okay, most Half the people, So progressive enhancement, Was coined around 2003? I — the name that pops into my head is Jeremy Keith’cause, he talked a lot about it, but I actually did some research And found it was coined before then, But progressive enhancement came around as People were designing advanced web applications to take advantage of the latest technologies.

And then were finding it wasn’t working well on older devices, older browsers, Older software et cetera, So the idea behind progressive enhancement was To start at the very basic make sure that say, your web application can be used. In older environments and then to progressively add enhancements, If the web application or the website is being used, In more advanced technology, So that was progressive enhancement of 2003.

Then in 2010 the idea of responsive Web design was coined, I think, by Ethan Marcotte in A List Apart, article And responsive web design is about Designing your website or web application so that it can respond to The device you’re using you’re looking at and on you’re using it with So whether I’m looking at a big desktop Or a small little phone that it will work and that’s responsive web design. I assume you’ve heard a lot about that Now, there’s something that Predates this by quite a bit In 1999, a similar idea came Out way before that, Anyone have any idea what that might be.

That’s the idea of transforming gracefully. So, in 1999 the web content accessibility, Guidelines talked about transforming gracefully, and that was again the idea. That we have the content that can transform no matter how it’s used So, whether it’s on a small device, whether it’s In a big device, whether it’s older technology, whether it’s newer technology, whether it’s Through a screen reader by a user who is blind, whether it’s in large magnification, however It is designed it will transform gracefully.

So the point in here is that These ideas aren’t new, We’ve been talking about those In accessibility for a long time, And when you start to think about Accessibility early, it can lead to a lot of these developments for what we’re talking. About now, for example, mobile web design, So if you want to be great, if you want To be great, get accessibility right And you may be hesitant and you Should be and I’ll tell you why It’s because you really need a Crack [ phonetic, ] accessibility.

You know that word. It means really understand. It really be one with it really understand the concept of accessibility, So that’s kind of the key to the key And I’m going to tell you a little bit about how that’s different than you May think of accessibility right now, So what I want to talk about is understanding. Accessibility differently totally differently than many people address accessibility.

A lot of people came to accessibility because They were forced to meet some standards or some regulations, so the web content Accessibility guidelines came out in 1999, although a lot of people didn’t directly Paid attention to them in the US, Then, when Section 508 came along all Of a sudden, this was a checklist. You had to pass the accessibility and there’s Been other regulations around the world where people then started approaching Accessibility as this thing, I need to do afterwards at the end of my Project I need to pass this checklist, But that’s not the right way to think About accessibility, so I’d like for you to change your mindset about accessibility, And we’ll talk a little bit about that As mentioned, I do work for the W3C the World Wide Web Consortium, and that is the organization that defines the Standards for the web, so html CSS et cetera.

We have a web accessibility initiative. That develops specific standards and guidelines for accessibility. So, given this is my employment, you Would probably assume I would say, step 1, the most important thing for accessibility, Is to know those standards and guidelines, But I don’t, even though that’s my Employment, that’s not the number one thing: If you just start out with the standards. And guidelines, it’s overwhelming You’ll be like a deer in the highlights right.

It’s too much, That’s not the place to start. Instead, the place to start is understanding. The basics of how people actually use the web: It’s not about standards. It’s about people, specifically people with Different disabilities and how they use web – That’s the number 1 thing and the Most important and the basic thing So, for example, I want to tell You about some people that some friends of mine that use the web One is Glenda.

I first got to know: Glenda Just from mailing list archive She was on a couple of similar mailing — Same mailing list that I was on, And I was just really impressed by how Articulate she was how clear how level headed when the conversation got kind. Of uncomfortable, sometimes she was always just clear and Not getting into the fray Really impressed with Glenda! Well, it wasn’t until years later that I Found out that Glenda has cerebral palsy, [ mumbling ], So that’s how she talks so Actually, interacting with Glenda face to face is much more difficult, but because Of accessible technology, she can contribute to this — the work just like anyone.

She has a blog. She is called the left thumb. Blogger, Because she also has limited motor control and she just types with one thumb. She slides her hand along the keyboard And there’s a article on there on YouTube. I think if you want to check that out, So Glenda is one of the people that we Need to focus on when we’re thinking about — thinking differently about accessibility, Another person who also has motor Impairment is a friend of mine named Carl and Carl lost use of his arms From polio from post polio, So he doesn’t use his arms at all.

He uses a mouth stick to type, So it’s just a dowel with a wooden tip at the End and his typing looks something like this [ Pause ]. He can type pretty fast. I don’t know what his words per minute are. He is also –. He can also Talk while he types as well, So we need to make sure that our Applications work for people like Carl. This is John Slatin John started losing his sight when he was middle Aged and eventually went all the way blind John was a professor English.

Professor at University of Texas, He embraced technology as a way for — in the Web –, as a way for anyone to communicate And John developed, leukemia And John needed to go to do research on Treatment options and what he found was that many of the websites That provided information on treatment for leukemia were inaccessible. He couldn’t get that information, So John is trying to make life decisions.

Life or death decisions literally, but the information is not accessible to Him and we need to make sure that all of our web applications website Is accessible to people like John He –, So people who are blind use screen readers That read aloud the information on the screen. I hope most of you have heard screen readers and Readed someone interact with screen readers. I won’t take the time to do that now.

But if you haven’t that’s top priority, Do it this really will help Change your thinking, Here’s another friend of mine, His name is John as well And John was born blind and he Started going deaf around age 8 All right, So he can’t use a screen reader. How does he interact with a computer Braille exactly? He has a dynamic Braille Display they are so cool, He has this rollup pins and it pops up and provides the Braille — The output from the computer, So that’s actually how John and I communicate.

We just have his notepad up and I’ll type on a Regular keyboard and he can read it in Braille and then he’ll type back in notepad And I can read it in notepad Because of accessible technology. John was Able to graduate top second in his class in Mathematics go on to get a master’s degree. In computer science and electrical engineering, So we need to make sure that all of our Work is accessible to people like John Now, one of the important things Is to be careful not to focus just on screen reader access and People who are blind So, for example, –, oh, you know I started out.

Talking about people with motor impairments, that was on purpose people who Have difficulty using their arms or such to interact with a computer? When we talk about visual disabilities, we Also need to be aware that a small percentage of the people with visual Disabilities are blind, A large percent are –, have low vision. So, for example, I have optic neuritis, It’s remitting, — remission — and comes and goes And a lot of times when I look at the screen, it looks something like this Which is the normal sized text? It is really too blurry to read, but The larger sized text is readable, So I usually use 120 150 percent Zoom in a browser and set up that way, But some people need more Significant screen magnification, So here’s an example of someone with Very significant screen magnification Okay, So they can only see Part of the screen at a time It has some overlap with, say, mobile design, where you can only see part Of the screen at the time, So again it’s really important when we’re Talking about even visual disabilities to realize a huge variation in user needs.

This is Tim Creagan. He is at the US. Access Board – and he is hard of hearing. This is another thing, that’s very important If you have audio on the web, whether It’s a article or a podcast or whatever, and you don’t have transcript or captions. That information is totally Inaccessible to a person who is deaf, A person who is deaf cannot get any Of that information in an audio, So if you’re not providing a text, Description, you are discriminating against those people who can’t hear Another very important thing to consider.

Another thing is this: — I’ve worked With a high school student named Sarah, who is going into a college program, Looking at her, you would not Assume she has a disability, but she actually has a fairly Significant visual processing disability. So when she reads text, she can’t understand it. So she uses a screen reader’cause when She hears text or she you know hears, she can process information, just fine.

She can see just fine, but she just can’t Process the information that she sees as well, So she uses a screen reader People with different cognitive disabilities. Are another group that we need to consider So if we think about all this, we think about People with auditory cognitive, neurological, physical speech, visual disabilities, you See how we can really open up our thinking. So if we think not about the checklist, not About the guidelines and the requirements, but who are we really designing for Who are the people? What are the issues? What are we really designing for? So this is to approach web design differently.

It’s a different approach to web design. Now, if you have a smartphone in your Pocket most of the technology developed for that smartphone came from Innovations for people with disabilities, So even the very basis of a phone — of the Phone comes from developments to accommodate and to help people with different disabilities. Elle Waters will do a presentation later. Where she’s going to talk some more about this, so I won’t go into the many many examples.

Of how something that was developed for a person, sometimes or People with disabilities is now in the mainstream technology. That you have in your pocket, But the idea is that thinking Differently leads to innovation When you’re thinking about all different people, On different situations, it really lead you to think differently and Innovate in new and unique ways, So how do you do that? How do you think differently? How do you consider all these people Any ideas You meet with them? Exactly you meet with them.

You can do very informal meetings. You can do more formal processes So, for example, a user-centered Design or user experience or usability has very specific Processes and techniques that you can use to understand how people use the web ISO has a definition of usability. Anyone know that You don’t have to repeat It but yeah yeah someone Yeah yeah, okay, So it’s the extent to which a Product can be used by specified users to achieve specified goals.

Effectively, efficiently and with satisfaction in a Specialized context of use, So that’s the definition of usability in ISO Now this is achieved through A user-centered design process How many people have heard of — know Basics of user-centered design process About half About half, So here’s the summary UCD is the user interface design. Process that focuses on usability goals, user characteristics, environment, Task and workflow It follows a series of well-defined methods and Techniques for analysis, design and evaluation.

It’s an iterative process with Steps built in from the first stage of projects through implementation, So the idea is that you can Follow user-centered design to understand accessibility, Understand how people use the web Now when we look at that definition, we looked at Earlier the ISO definition of usability. Look if we pick out a few words, so It says “ Use by specific users,.” And all you have to do – is Make sure your definition of those specific users includes People with disabilities, people with a wide range of abilities And then it says, “ In a specified Context of use.

”, So that’s making sure that the context of Use is broad that it includes, for example, assistive technologies like screen readers, And screen magnification et cetera. So if you know any usability specialists Or user-experienced professionals, this should be right up their alley. Now some people are onboard and some People have yet to see the light If you’re a developer and you Want to go beyond the checklists, follow usability principles will help — and Methods and techniques will help you with that.

So if you want to learn more About this, the W3C WAI has some information called Involving users in web projects for better easier accessibility – And this is mostly geared towards developers, Designers developers not particularly Usability specialist, but just you know you said, observe people This talks about finding people and Observing them talking to them, So that’s some basic information. Now, if you know someone who is usability, Specialist or really wants to get involved with this I’ve written a book called “.

Just Ask Integrating Accessibility Throughout Design,.” And the whole thing is online free, So it’s available from uiaccess.Com/justask. So it’s uiaccess.Com/justask And that’s all about –. It’s primarily Geared towards usability professionals, but the beginning is the basics. That you can implement, even if you’re not doing full User-Centered design process, If you’re interested in getting a print copy for those who are here, we Have a discount in November! So from that website you Just enter a11ymtl.

Html and you can get a discounted Version if you want to print a copy, But the whole thing is online for free as it is So that’s another resource We’re going to look at a few Other resources that we have from the W3C WAI on designing for inclusion. We have an extensive document on how People with disabilities use the web. It has several different Sections one it talks about just like the user stories to Help bring those to life.

There is a section on the Technology that people use There’s a section on what are the accessibility, Requirements of websites and web tools, So I encourage you to take a look at How people with disabilities use the web? We have another resource called Web accessibility and older people on meeting the needs of aging web users, So we had a three-year project that Was a European Commission-funded project to look at designing for older users And what we found at the end of that Three-Year project was that indeed, it’s a one-on-one overlap with Designing for accessibility, So we already know how to Design for accessibility And what we found is it’s the same issues.

If you’re designing for older users, because older users have a range of issues, Let’s do a little exercise to that and Give you a chance to stretch your feet So I’d like everyone to stand up. [ Pause, ], Okay. So what I’d like is for you to pick One of the gray figures on the screen, So on the screen we have a representation. Of the percentage of people with disabilities, This is in the age group, 18-24 years, okay And it’s 9.

5 percent. So pick one of the gray figures We’re going to go through aging And if your figure turns Color have a seat okay, So this is 25 to 34 years 10. Percent and we lost 2 3 people there. This is 34 to 44, 14.4 percent, 45 to 54, 21.2 percent 55 to 64 at 34 percent, So more people dropping 65 to 74, it’s 42.3 percent 75 and over 64 percent Now look around the room. We have less than 64 percent, We have four people standing, So those of you who are standing Unfortunately, this isn’t the true predictor of real life, so I can’t guarantee That you’re going to make it without Thanks, you can have a seat, But the point is, most of us will live to 75 and Most of us will acquire significant disability.

Minor disability at first may be from Declining eyesight from declining dexterity from declining hearing all These — cognitive disabilities – All these are significant. This can start out small. It can get really annoying And but can be much more of an impact. On how people use your web products Designing for people, older users is becoming More and more important and more and more of a focus of both government and Industry and on profits and everyone, This is focused on meeting the User — needs of older users And, if –, in order to do that, you can look At what we already know about accessibility, So that’s the –.

We have resource on that. We have another resource on web Content, accessibility and mobile web, So I’ve mentioned some just Briefly, the overlaps, but we have a specific document on that overlap. Now this talks about how the standards And best practices overlap between the two, So I just said that word standards, Even though at the beginning I said that The standards are not the first place and not the most — the first place to go.

They do play an important role, So I still say that the first Step is to understand the basics, But maybe around step 3 is to start Looking at the standards and guidelines and then probably again, maybe at Step 7 or somewhere around there, So they do have an important role. One other reason is there’s no way you Can fully incorporate enough people and enough variety in your design process. So, even if you have a huge budget and a Huge amount of time, there’s so much variety in people in how we use the web and how People with disabilities use the web that you won’t be able to cover it all, And the standards and guidelines do that.

For you, they consider this wide-range, So I’m not going to go into detail on these. I’m just going to make sure you know. What’s There and then hopefully you can –. If there’s any questions, we can Follow up with that afterwards, So again, the W3C defines its standards. For the web and the ones we have for accessibility are an integrated set, So you may have heard of WCAG or the Web. Content Accessibility, Guidelines that applies to websites that applies to web applications.

That applies to mobile applications. Everything Then another aspect of the Guidelines is that users use browsers and other technologies to access the web, And we have guidelines for those called The User Agent Accessibility Guidelines – Another one – is the Authoring Tool: Accessibility, Guidelines and that talks about what the tools that we use to design web content Need to do to support accessibility.

These are built on the technical Specifications from the W3C, We also have some specifically for Accessibility, such as the WAI-ARIA for Accessible, Rich Internet Applications and Indie UI, which is Independent User Interface, and that talks about how to Communicate a user action to an application, no matter how the user did It so whether they scrolled with a gesture whether they used a mouse, whether They used voice input, however, Okay, so just a brief introduction.

Also A note that WCAG 2 is now an ISO standard. So if you’re working on WCAG 2, now you can Say you’re also working on an ISO standard. It’s exactly the same. The same text, It’s just adopted now as ISO/IEC 4500. Again, if you have any questions I’ll Be around at the break and afterwards, So I just want to reiterate that Accessibility is about designing your website so that more people can use it.

Effectively in more situations, It’s much more broad than just Focusing on people with disabilities, that’s the most important aspect that we Focus on but the benefits are far reaching. So if you understand accessibility differently, It’s not about a checklist to do at the end, but it’s a fundamentally different Way of thinking about your web design and your web development It’s not about the checklist, If you understand accessibility differently.

You will approach web design differently And an interesting article from A List, Apart several years ago by John Allsopp, is called The “ Dao of Web Design.”, He says “, Firstly, think about what Your pages do not what they look like Make pages that are adaptable. The journey begins with letting go Of control and becoming flexible.”. So when you change your way of thinking, You’ll understand, accessibility differently, you approach web design differently, and this is A catalyst to greatness greatness in usability and user experience for a wide range of Users, whether it’s on the mobile platform, whether it’s because they are older, it’s All these things that you want to do better at you can learn from understanding Accessibility, So I encourage you to approach Accessibility as a catalyst to greatness – and I thank you for your time – [ Applause & Music, ],


 

Categories
Online Marketing

Best UX practices and mobile first

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.


 

Categories
Online Marketing

Best UX practices and mobile first

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.