Tuesday, 24 July 2018

Principles of Design - Oh, and Tasks

Well, let us start with tasks. Not so much tasks in relation to getting information, but tasks that need to be done in the system. Let us consider a real world example, such as eating. There are a number of ways that we can go about it, for instance we could cook it ourselves, we could go to the restaurant, or we could order takeaway. We could also choose to go on a diet, but that would be a bit silly. Anyway, each of these tasks have a number of subtasks, and requirements. For instance, with getting takeaway, we need to find out if the store does takeaway, and whether we want Chinese, Thai, Indian, or just plain old fish and chips. We could even go down to the local supermarket and get one of those frozen meals, but they don't tend to be all that filling.

Not quite the task list I'm talking about

The same goes with systems - each of them have tasks, and we need to consider a number of subtasks. For instance, say we want to fly to Kuala Lumpar. Well, as it happens there is an app for that (though a friend is still pining about the fact that there isn't an app for her to find a boyfriend, until I directed her to OK Cupid). Thus, we have a task, so we need to define the subtasks, such as typing in the dates we want to travel, and then choosing from the list of options and deciding whether you wish to go via Singapore, Hong Kong, or go direct with Air Asia (if you can handle budget airlines, which I can't, though Air Asia actually wasn't as bad as I expected). Finally, we need to consider how we are going to pay for it.

So, when it comes to tasks, we need to define what the task is (booking a flight), determine how often it is going to be performed (not too often, unless the user is a frequent traveler), and how long it should take on average. Then we need to consider how a new user will learn how to perform the task, how they would respond to the design, and how intuitive the actions happen to be. Since the task we are attempting to define is actually one that isn't going to be performed all that much by the casual holiday maker, then we need to remember that in a lot of cases they are going to be first time users everytime they want to book a flight. We also need to consider what could go wrong, but that can be problematic because as Murphy's Law states: anything that could go wrong, will go wrong, such as the user experiencing a power outage in the process of arranging the transaction.  However, in determining this, what we do need to consider is whether there will be any other users involved, and whether any third party software is required (such as Paypal for the payments). So, I guess the big question then is, what are the risks?

A Few Principles to Consider

Now it seems as if the world of User Centered Design has created a new word that I have no idea what it means - Heuristic. Basically they are a set of principles that we should keep in mind when developing a piece of software, and they are quite user focused. Now, there isn't actually one set of principles that everybody follows, particularly since there is one lot that has 30 principles, and another with something along the lines of 644. Now honestly, that is getting ridiculous, particularly since they have ceased to be overarching principles, and more akin something you would find in your local law library. Anyway, the ten basic principles that we have gone with are known as Neilson's ten Heuristic Principles (and apparently we have to memorise them for the exam). So, let us now look at then one by one:

Visibility of System Status
This principle basically suggests that the user should always know what is going on, and how long it takes. For instance, if the computer is saving a big file to disk, but doesn't actually tell the user, then the user might just think it has crashed. Further, if we don't know how long it will take, because users are impatient, and expect way too much from computers, then once again they are likely to think the system has crashed.

Match Between the System and the Real World
This really comes doing to being intuitive. Notice how these days email apps look like, well, a letter. Okay, a lot of people probably don't know what a letter actually looks like these days, but that is something that has come back from the time when people actually communicated by what was known as snail mail (because it took a long time to get to where it was going). The idea here is that by using real world symbols, people can intuitively know what the button does. Want a button to stop something, then maybe shaping it like a stop sign will help. Mind you, I'm still a little baffled as to why Microsoft insisted on putting their 'turn the computer off' function under the Start Menu.
User Control and Freedom
The thing is that users really don't want to get locked into doing something, especially if they have gone somewhere where they don't want to go - such as that dodgy website that they have landed on, or they are having second thoughts about sending that email declaring their undying love to the person they have a crush on. The thing is that people need a way to back out of what they are doing, or stop heading down the path that they are heading, and this needs to be taken into account when developing an application.

Consistency and Standards
We really need to be consistent across all platforms, and that applies to the real world as well. For instance, what would happen if one town decided to be different and instead of going on green instead went on red, and stopped on green. Well, confusion is certainly going to reign. The same is the case with computer systems - if there is an accepted standard we should go with that accepted standard, no matter how much we may not like it. Sure, we might hate that envelope as an email, but unfortunately we have to swallow our pride and go with it, instead of experimenting and using Marvin the Paranoid Android instead. Mind you, the Americans seem to have stubbornly refused to go over to the metric system (and the British still drive on the left).

Error Prevention
Simply put, we really can't have the app crash on us, do we? Honestly, how frustrating is that, when you go into the app and it suddenly shuts down because it has crashed. This, in many cases, is a programming issue, and we should be looking for ways in our programs to avoid these errors, particularly since it could result in even more disastrous outcomes than the simple annoyance of not knowing how many people liked your last Facebook post.

Recognition Rather than Recall
This has probably been covered in the previous post, but it is important and should be reinforced. Basically people don't like learning things, and they certainly don't like remembering things (particularly in the days where we have so much information a Google search away). As such, if the user isn't all that regular, or even new, they should be able to use the product without forever going to that help menu, or randomly pressing buttons hoping they get the result that they want.

Flexibility and Ease of Use
So, how many ways is there to copy text in Microsoft Word (or I probably should say Libra-Office, but since I got Word for free, I do happen to be using that). Well, you can go to the menu, select edit, and then select copy; you could right click on the high-lighted text and select copy; or you could simply press ctrl-c. This is what this principle is about - while it should be easy to understand and use for the novice user, there should be shortcuts for the experienced user. In fact, ever since I started computer science I've found myself using even more of these shortcuts (ctrl-B to turn bold on or off).

Aesthetic and Minimalist Design
We call this the 'Google Principle' because Google is the prime example. Basically their home page has very, very little - a search bar and title in the middle, and a few buttons elsewhere. This is in contrast to, say, the old Yahoo page which was just cluttered full of links and whatnot. What the principle does is that it focuses the user on the important part of the page - the search engine, and pretty much discards everything else, namely because it just works as a distraction. There are plenty of other places to put distractions to keep the user on your site, or using your app.

You're probably too young to remember this

Help Users Recognise, Diagnose, and Recover from Errors
This isn't so much the user going somewhere they didn't want to go - that is dealt with elsewhere - no, this is the user doing something they aren't supposed to do, such as entering 'I love pineapples' in the box for the phone number, or typing in some malicious code that will completely wipe your website when they press the 'submit' button. Here, when the user has done something wrong, the computer should not only inform them that they have done something wrong but guide them to do it correctly. Mind you, this warning and guidance shouldn't be:

Help and Documentation
When worse comes to worse, the user should know where to go for help. Mind you, when I was growing up, there was this expectation that men never looked at instructions, and this is probably still true. Sometimes, though, we want to know how to do something, or something has been changed, so instructions not only need to be easily accessible, but also easy to understand. In fact, instructions really should be short, sharp, and shiny, as they say.

Evaluating Everything

So, now that we know what these ten heuristics are (though as I have mentioned there are more), we need to know how to evaluate them. This is where the results of our surveys come in. So, once we have discarded the pointless responses, we can then review them and determine what the real problems are. In fact, when the surveys are constructed, they need to be constructed with these ideas in mind, since it makes it easier to isolate the problems. Mind you, constructing the surveys is also important as we need to be careful not to create loaded questions and the like, or questions that direct the respondent to a certain answer (it is true that strawberry icecream melts faster, doesn't it?). 

So, now that we have identified the issues, what we do is to rate them on a severity scale, and then it can be determined which ones need to be attended to, and which ones can wait. One of the issues is that a lot of the evaluations are performed by usability experts, but they tend to be few in number, and not always regular users of the application. As such, it may be helpful to approach the users directly, considering time and budget constraints of course. Yet, as mentioned, relying entirely upon expert opinion could be a problem in and of itself because, honestly, some experts are only experts because they speak as if they were experts.

Design Principles

Now, these aren't strictly heuristics, rather they are principles that should be taken into account, depending on the context of course. There are quite a few of them, however we will only touch on a couple here:

Principle of Proximity
Basically this principle is about things being close to each other. You know when those really annoying adds pop up when you are playing that game on your phone? You know how when you go to cancel out of it you end up on the Google Play screen? Well, that is the principle of proximity at work, though in a way that is not really what it is supposed to be. Basically, similar buttons should be next to similar buttons (such as copy and paste).
The other aspect is that functions that do similar things should be grouped together. Notice how in word processors all of the font icons are next to each other, and the paragraph styles are also next to each other. Actually, lets illustrate this principle by looking at the toolbar for Blogger, since I am using it at this present time:

So, from left to right, we see the undo and redo buttons, the font and text style buttons, the app buttons, and the paragraph style buttons. It wouldn't do well to have the bold selector next to the block text icon, and the italics icon between the undo and redo icons - it just wouldn't make sense, and it is also confusing. Sure, you could try to be different, but don't expect anybody to actually use your app.


There is a very simple way to illustrate this principle:


stands out much more than:


The reason being is that visibility is used to catch our attention, therefore more important items should be used to highlight important points. Notice that writers do this using italics and bold (and usually add 'emphasis mine' afterwards). This is because they want to make a point. Notice that links are also highlighted, which us usually done to validate what is effectively fake news.

There are other techniques used as well, such as transparency. Where something is not important, or should actually be put aside (but not removed) for a short period, it should be made transparent. There are lots of other suggestions, such as typeface, colour, and contrast (and also an idea that logos should not take up more than 25% of the screen), but I suspect this makes the point.

This is basically the art of making it impossible for people to do the wrong thing. Take socket heads for example (at least here in Australia). They are designed in such a way as to prevent people from putting them in the wrong way. Mind you, there is also the idea that it doesn't matter whether you make something idiot proof, people will just build a better idiot.

Finally, I will finish off with a couple of design laws, the first being Hick's Law. Basically that law states that the more options that are available, the longer it takes for somebody to make a choice. Have you ever been to a restaurant that pretty much serves everything? It takes a lot longer to go through the menu than a place that only does, say, hamburgers. Then again, that is a pretty poor example because if I go to a restaurant with nothing particularly appetising on the menu, it will take ages for me to make a choice. In short, Hick's law pretty much states that when creating menus, get rid of things that aren't really going to be used.

Then we have Fitt's law, which states that the bigger something is, the easier it is to hit. The best example of this is the pedals on your car. Notice that the brake is much, much bigger than the accelerator. This is to stop you from hitting the wrong pedal in an emergency. Anyway, it is generally better if you accidentally hit the brake than accidentally hitting the accelerator because the person that hits you from behind is always going to be at fault (though I wouldn't recommend attempting that on the German Autobahn).

Anyway, that's it for now. Next time it will be back to surveys (because it will probably be examined), though Boolean Algebra won't go astray.
Creative Commons Licence

Principles of Design - Oh, and Tasks by David Alfred Sarkies is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me

Monday, 16 July 2018

Playing with Numbers - Addition & Subtraction

A part of me sees maths as simply one big game that involves numbers, its just that some of the ways that you play with these numbers can be particularly complicated, such as the following:

Now, I'm not going to attempt to solve, or show anybody, how to solve this particular equation, especially since it resulted in lots of people losing lots of money, but is one of the reasons why investment banks and the like are still willing to pay people with maths degrees and awful lot of money to work for them (and the guys that came up with it also won a nobel prize for the equation, though honestly, after it failed catastrophically, I'd want to take it back). Anyway, you can read more about it here.

Instead, we are going back to basics - sort of. While one might consider addition and subtraction to be relatively easy (even without a calculator), when we come to alternate number systems, things do get a little complicated. However, before I go any further, there is something of notation that I should mention. First of all, what are the following numbers?

If you said 'ten', 'ten', and 'ten' then unfortunately you would be wrong. In fact those numbers are actually 10, 2, and 8. The reason is that they are all different number systems, the first decimal, the second binary, and the third octal. So, how do we tell the difference? Well, if nobody has indicated what numbering system they are using, then you don't. However, to solve that problem, it is common to use subscripts, as follows:

Adding Things Up

So, now that we have that out of the way, let us first go to addition. Okay, I will assume that most people understand how to do arithmetic (without a calculator of course) so I won't go any further. However, remember how we used to do long addition, such as adding 7569 to 8167? The following is probably a reminder.

Now, you would add up the columns, starting from right and going left. However, if a the answer was over 10, you would put down the rightmost number, to put the one as a subscript in the next column. You would then add those numbers, as well as adding the one as well. If the resulting number also exceeded nine, you would do the same, until you had the answer.
Now, adding up binary numbers is pretty similar, except the problem is that you are only dealing with 0s and 1s. So, when you add 0 to 1 and vice verse you get, well, 1. However, what happens when you add 1 to 1. Well, you get 2, but 2 doesn't exist in binary so you need to carry the one, and the resulting answer is 10. However, what if you have already carried a 1? Well, the answer then becomes 11. An example follows:

Now, did I hear somebody suggest that there was an error. Shouldn't the answer be 11001001011? Well, yes, and no. Okay, this is only an example, but if you count the number of digits you will notice there are 10. Okay, 10 bit systems don't exist, since they basically increase by powers of 2, so it should actually be a 16 bit system. However, I did it this way to show something, namely what happens when it reaches the maximum limit - it drops.

Actually, I would say it crashes, and it can crash, as what happened with Gangum Style. What happens here is called a 'buffer overflow error' in that there isn't enough room for the total number of digits. Fortunately, these days computers are a little bit smarter than what they used to be, and usually what happens in this situation is that they just move on to the next load of data.

And Taking Them Away

I was going to add another section involving floating point numbers, but the lecturer has indicated that it isn't examinable. Then again, you can never go on what a lecturer says is examinable or not, because sometimes what is said won't be in an exam ends up being in an exam. However, the whole floating point concept is pretty intense and deserves a post in and of itself, so I'll just finish off here by talking about subtraction.

Now, when it comes to subtraction the rules unfortunately change - a lot. This isn't a simply method of simply subtracting 1s and 0s because, well, all you are dealing with are 1s and 0s, which means that it gets pretty confusing. Not just for us, but for the computers as well. Remember, this whole thing about binary is that we are attempting to speak to a computer in a language that a computer understands, and in many cases it is a completely foreign language (despite the fact that computers are artificial).

Now, let us get to negative numbers. Unfortunately, when we are using 0s and 1s there isn't an easy way to tell a computer whether there is a minus sign after the number. Well, actually, there is, but you need to do it using only 0s and 1s. This means that what we do is reverse the final bit to indicate whether it is a negative or a positive, where a 0 says positive, and a 1 says negative. As such 0001 will be 1, but 1001 will be -1.

Well, not quite, because you need to invert the whole number. so, 0001 is 1, but 1110 is actually -1. However, there is a problem. Can you work it out?

Yep, 1111 would in this instance be -0, but there is no such number as -0, so what they do is that they add 1 to the number so that we don't have that problem. This system is called twos complement. As such using four bits, we end up with the following system.

0000  0
0001  1       1111 -1
0010  2       1110 -2
0011  3       1101 -3
0100  4       1100 -4
0101  5       1011 -5
0110  6       1010 -6
0111  7       1001 -7
1000  8

Well, that seems to have caused us a little issue, because -8 becomes 1111, but we add 1 to it and it turns into 1 0000, but nothing is perfect. Anyway, we are working with 4 bits here, so 1000 is slightly out of our range.

So, when we are subtracting numbers, we convert the number we want to subtract into its negative, and then add them, as such (using 3-2):


Okay, so we have an answer (noting that the final one has dropped off). We need to take note that the final bit is a 0, so we don't have to do anything with it, so we have our answer: 1.

Let us do something different, let us try 3-5:


Okay, our answer is 1110, which looking above converts to -2. The reason we know this is because the final bit is a 1, which means that we are dealing with a negative number. If you do have to do any of this in an exam, it is always good simply to scribble the numbers on the page, so you can easily reference them.

ASCII and Unicode

So, we have numbers worked out, but what about all this other stuff you see on the screen, such as these letters and other symbols. Well, that is set up using a different system, though it is all binary to the computer. Originally they worked on a system called ASCII, or American Standard Code for Information Exchange, and was common for the old 8 bit machines. In fact ASCII only used 8 bits, which meant that it was limited to only 255 characters (and you should also note that in ASCII 1 isn't represented as '1', it is actually '011 0001'. Anyway, here are some more ASCII characters, though the full set can be found on wikipedia

So, with there only being 255 characters to fiddle around with, how do we do things these days with our much more powerful, and much more fancy computers? Well, other than mining Bitcoins, they use a system call Unicode, which currently has over one million characters defined.

Anyway, I'll finish off here, and move on to Boolean Algebra (sort off).

Creative Commons Licence

Playing with Numbers - Addition & Subtraction by David Alfred Sarkies is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me