Saturday 28 March 2015

Dark background? Light background? Help!

In my presentation not too long ago, Dave mentioned a way of making the screen darker so that people would feel more like they were focused and "zen", rather than being confronted with another bright screen to look at.  When speaking to Simone about this, she suggested trying a dark background with white text.  At first I was all for it, but when I tried them out, I ended up not liking too much at all!  I felt a bit unsure, so I did some research on the readability of white text on dark vs black text on white.  As it turns out, the internet is as unsure as I am.  Some people are avidly "pro-dark background", denouncing the eye-straining implications of a light background (it should be noted that most of the time the light colour in question was in fact white) and saying that dark backgrounds help the eye to focus.  Others say that white text on a dark background is unwise due to many people having an astigmatism, a condition where the eyes find it difficult to focus which affects a not insignificant number of people.  "People with astigmatism (approximately 50% of the population) find it harder to read white text on black than black text on white." (Harrison, year unknown)

When I showed the examples to my supervisor, she again leaned towards the darker background images but ultimately admitted she was on the fence about either one.

In terms of evidence in literature studies, most suggest that dark text on white background is the better option for readability.   Scharff and Hill (1996) tested usability of inverted colour schemes and found that "the most readable colour combination is back text on white background; overall, there is a stronger preference for any combination containing black." Additionally "White on blue and yellow on blue were ranked fairly high…" and "…in every other colour combination surveyed, the darker text on a lighter background was rated more readable than its inverse."

A study at the University of Toronto used algorithms to determine whether the difference in hue between text and background should have a high readability.  It was found that: "In the case where the background was brighter than the text, this difference was found to be positive. For this instances in which the text was brighter than the background, this difference was negative."

A blogger writing for UX Movement (2011) writes that: "…a better choice for displaying paragraph text is black light text on a light background with a hint of tray (sic).  With a non-white background, less light reflects behind the words, making it easier on the eyes.  The black text works better because black is also a colour that doesn't reflect light on any part of the visible spectrum."

However, in the same article it is written that white text on a dark background works well when users are scanning their text, instead of deeper reading as would be seen when reading paragraphs.  "Users typically scan headings, titles and labels.  Using white text on a dark background for these types of text is an effective way to highlight them to get the user's attention.  This is because white reflects all the colours of the visible light spectrum into the eyes.  This makes the text bright and distinct.  You don't have to worry about putting stress on the user's eyes because scanning these types of text doesn't take long visual fixations."

This is something to take into account, as one of the things often discussed in my supervisor meetings is how to avoid the user's eyes becoming strained or stressed while viewing the app.  It would be a bit of a paradox if an app encouraging them to relax was actually causing a little more distress!  Another reason this particular section relates is that, at the moment, my text information on each page is mostly in little columns, meaning that information would be read in "snippets" and would therefore have to be visually clear.

The same article does say that "…if your site uses a dark background, display your paragraph text in gray (sic) instead.  This won't put as much stress on the user's eyes because gray (sic) text isn't as bright as white text." (UX Movement, 2011)  An additional point, which is relevant to my discussions with Simone about where and when people would use the app (her thoughts are that may people would use it at the ned of the day to do the exercises), came up.  "Keep in mind that if you're reading text in a dark room, where no light is present, then white text on a black background isn't always as hard to read.  This is because no light is reflecting on it in a dark room."  (UX Movement, 2011)

Some examples below of dark and light versions.



I had to go through pages and alter some shades where the blue was too muted or pale against the background, to maintain a good contrast.  Some studies of informal literature about inverted text schemes noted that white is too harsh on the eye as a colour for text and sometimes as a background colour as well.  Ditto black - a dark grey is much better suited to the eye.  For this reason, I set the dark grey to 75% on the Greyscale slider and the pale grey to 5%. 



I have to say, I do feel as though the blues and yellows pop against the dark grey better than they do against the neutral tone.  This is probably due to the grey being cooler in tone than the taupe-y colour. 





After making these, I also looked at websites with dark backgrounds to see how they worked with colour and what shades of white or grey were used.

Fig 1

Fig 2


The LA Bubbly site shows that the paler colour for text works better against the black background.  There is just enough contrast to be able to read the darker grey text, but this only works because the text is large.  The body text in my own work is too small for the same tone to be used.   

Fig 3

This is unrelated, but the subtle depth of the buttons here is really nice.  I have noticed in my work that sometimes the buttons look "flat", which could be changed.

Fig 4


Fig 5

The pops of colour against the black work really well here as the circular shapes are defined by the negative space.  This is the same layout that I am using in my screens, so there is a bit of proof that a dark background could perhaps work.

And just for good measure, some white background designs too!  Here I paid attention to which shades of grey are used in the text.  Mostly it is a middle to dark grey, rather than black, which might be because black is too harsh against the crisp background. 

Fig 6

Fig 7

Fig 8

Some pale shades do not provide enough contrast, as seen above. 

Fig 9

So there is evidence everywhere in screen design that both dark on white text and white on dark can work, which means I'll have to likely make my own decision on the matter.  Since I am going to put my survey out soon, Simone and I agreed that it would be a good idea to include images with darker backgrounds and ask respondents which they preferred.  It will be interesting to see which one comes out more popular!

Image References

JusDot, unknown.  Just Dot Media Services website [online] Available at: www.justdot.com
[Accessed 27th March 2015]

LA Bubbly, 2015.  LA Bubbly website [online] Available at: labubbly.com
[Accessed 27th March 2015]

Lloyd, Peter. 2014.  Handsome Copy homepage [online] Available at: www.handsomecopy.com
[Accessed 27th March 2015]

Apple, 2015.  Mac Pro homepage [online] Available at:
[Accessed 27th March 2015]

Trananh, Jackie.  2013.  Jackie Trananh homepage [online] Available at: http://jackietrananh.com
[Accessed 27th March 2015]

Francies, Craig. 2015.  Crazy Designs UK website [online] Available at: http://crazydesigns.co.uk
[Accessed 27th March 2015]

Flattyshadow, 2014.  Flattyshadow homepage [online] Available at: http://flattyshadow.com
[Accessed 27th March 2015]

Apple, 2015.  Apple Macbook Pro page [online] Available at: http://www.apple.com/macbook/
[Accessed 27th March 2015]

Friends of The Web, 2015.  Friends of The Web Homepage [online] Available at: http://friendsoftheweb.com
[Accessed 27th March 2015]

Thursday 26 March 2015

Bringing in some breadcrumbs

In tandem with designing the accordion menu, I created the breadcrumbs I had been meaning to do for so long.  It was important to look at other examples first, as I have a large number of pages to reference.




Using the greater than sign was a no-brainer, as the sign itself denotes "leading to" if you remove it from it's mathematic context.  I liked the banner look and was considering it, but after looking at all the content already in place I decided a text-only breadcrumb style was best, to keep negative space.



I knew when I started applying the breadcrumbs that I wanted the "current page" to be in bold, as I had done with the numbers in the top right hand corner.  I felt that the bold on it's own did work, but after trying out a little box with a drop shadow around it, I decided that this gave just enough of a "pop" to the text.  While the breadcrumbs should be low down on the hierarchy list, I felt that highlighting the page was validated as it might help the user to orientate themselves that little bit more.


Example of breadcrumb design as is on the "Body Scan" page.



Accordion menu making

Ahead of some final iterating before putting the app out to a survey, I made an accordion menu layout as discussed with Simone, as well as adding in a style of breadcrumbs I was happy with so that the user would know where they were in the app.

"The purpose of an accordion menu is to manage an overabundance of content through dynamic switching." (Rocheleau, 2015)  For this reason exactly I chose to create one, with links to the core pages.  I considered adding in a fly out menu which would extend these sections in a second sub-meu, but ultimately dismissed this as it is far better suited to a computer's mouse/track pad gestures than a mobile device, which would rely on tapping to navigate.  In addition to this, I checked with the instructional videos on the InvisionApp site and saw that there was no apparent way to create this! Furthermore, when I discussed it with Simone she agreed that it was perhaps not needed.

First, I looked at the web flowchart and decided which were the most important pages for users to refer back to for their search journey.  These will be the main sections of the accordion menu.


Next, I looked at examples of accordion menus which mimicked the iOS style, as well as ones I thought would work stylistically.

Search dropdown by Alexandre Naud

Menu (Rebound) by Nicola Arminelli

Free PSD Accordion Menu by Wassim


I then created a draft of the accordion layout and duplicated it a couple of times to test colour schemes. 
After looking at the ones I felt were well designed, and keeping in mind what Simone said about mimicking Apple's style of user interface, I went for a look that was quite skeumorphic.  This may well change, because it does look a little more 3D than the rest of the page.


I tried out a couple of different fonts, the look of which I felt fit with the mood of the app.  It was a close call between my chosen typeface Arvo, and Armanth, which is seen in the image below. 


Once this was done, I tested how it looks over the page layout. (At the moment I am deciding between dark text on a pale background and grey-white text on a dark background.  Going to detail that more in another post, because there's quite a bit of literature making the case for the readability of both.)  I kept the typefaces and colour scheme consistent.  



Simone suggested that having a contrast between the accordion menu and the main background colour would work for the paler screen as it did in the darkened background (above).  The one I use end of course will be determined by the tone of the background colour.


So at this point, with regards to the menu, all there is to do is for me to implement it in InvisionApp.  I hope to get that started tomorrow as I have an iPad for the day from the Hannah Maclure Centre which I can test on.

Image references:

Armellini, Nicola.  2011.  Menu (Rebound) [online image] Available at: 
https://dribbble.com/shots/320535-Menu-Rebound?list=searches&tag=accordion
[Accessed 25 March 2015]

Naud, Alexandre. Date unknown.  Search dropdown [online image] Available at: http://www.uiparade.com/portfolio/search-dropdown-2/
[Accessed 25 March 2015]

Wassim.  2012.  Free Psd Accordion Menu [online image] Available at: 
https://dribbble.com/shots/663761-Free-Psd-Accordion-Menu?list=searches&tag=accordion_menu
[Accessed 25 March 2015]

Article references:

Rocheleau, Jake.  2015.  Best Practices for Accordion Interfaces.  [online] Available at:
http://webdesignledger.com/web-design-2/best-practices-accordions-in-web-design
[Accessed 25 March 2015]

InvisionApp tutorial (for reference):

http://support.invisionapp.com/hc/en-us/articles/203328329-How-can-I-create-a-drop-down-menu-

Tuesday 24 March 2015

Dangers of fracking scrollable

I came across this one while in a slump and looking at good examples of information design to inform me a bit.  This is a scrollable information graphic on the dangers of fracking, which is designed in a way that mimics the fracking process in a downward reading pattern.  The vector illustrations, light but muted colour scheme and serif typeface (looks like Georgia) are kind of similar to my own work.  The way important information is highlighted in colour is something I've not really done before.




The textures used here are really subtle, which makes me think I should re-visit putting some paper scans in mine.


Information is linked to the illustration through proximity.  There are no linking lines or arrows but the linear layout accommodates for the lack of this.  The bounding box for text, with the lower opacity white, provides a paler canvas for the darker text.  Everything illustration-wise is very geometrical so the boxes around text compliments this.



http://www.dangersoffracking.com




Bringing in type to layouts

A couple of weeks ago I began to input information into my page layouts, as most of the brain process illustrations were done and it was time to stop shirking what I felt was "the difficult part".  So far it's been a continually iterative process, which even now is ongoing!

 As I think I mentioned in a previous post, I am toying with the idea of having some images in my survey with serif fonts, and others with sans-serif.  This is because, as I will detail a little bit more in an upcoming post, the whole "sans-serifs are a rule for screens/actually it's OK use serifs" debate seems to still be largely unresolved.  My personal feeling is that I can use a serif font for the body text, however there is supporting literature for both sides of the argument.  Since I shouldn't base a design intended for other people entirely on my own opinion, I hope to gauge some helpful feedback from the survey.

The typeface I used for most of the banner headers here is Bebas Neue, and the body font is Chapparal Pro.   Since Chapparal Pro is a serif, I felt it had a friendlier "tone" to it and that it could complement the style of the illustrations.


In pages that are intended to be modal windows or similar, the illustration was kept centre and annotations usually placed on either side.  In the example above, the essential points of the subject matter are both on the same side of the page, so in cases like this text is placed under the image.  I am attempting to "preserve" space at the bottom, because this app will be viewed on an iPad in a landscape orientate which means that the iOS navigation bar would pop up at the bottom if activated.  Putting content too low on the page would interfere with this.


I was quite into having the boxes at the bottom in a dotted line, but my supervisor pointed out that this meant there were too many dotted lines in the layout and the eye would get a bit confused.  Since the dotted lines are used in a semiotic sense to indicate a link or an idea, it doesn't actually make so much sense to have them as bounding boxes.  I may, however, use the same style of bounding boxes as seen lower down this post, because I feel that they are a good "anchor" for the text.



The examples shown here are what the dotted line could be used for - linking things together that are not physically or explicitly linked as is. 


In some earlier illustrations, I use white dotted lines to outline areas of the brain that are highlighted.  To me this adds a bit of depth so I am planning to keep it.  In later text implementations, I kept the linking line white too - perhaps if I try iterating the images to include this the link between information and text will be a visually embedded a little further.


I was advised to remove the "tab" look as seen above as it didn't suit the navigation, but was happier with the contrast the paler box provided against the text.  This led to me eventually creating bounding boxes for the text in the same value of white (70% opacity).  See this further down the page.


In the example above, I started trying to frame key words and establish a text hierarchy through use of bold font and darker hue of grey.  It was decided that black type was too heavy and stark on the page, so a muted grey would be used instead as there is still adequate contrast against the background.  The words also "float" on the page a little, which may mean that some information gets lost without a shape or backdrop to ground it.  In the image below, I tried to see how a (obviously a bit off-kilter!) bounding box would look.  While a singular box highlights an important piece of information, I don't feel that it guides the eyes in the direction I want them to go, as it is nearest the bottom of the page.



The family tree layout came about from trying to link the illustrations together by something that suggested a connection, rather than a proper line drawing elements together. 



The same layout was applied to the "about this course" section, as seen below.



The how to guides were a little different and took a few attempts to arrange.  Even now I'm going to have to look back and re-shuffle, looking more at Gestalt theory, readability and saccades of the eye (in relation to how long each line of text is).

I tried out different headers when I got to this stage, as I was really sick of the banner look and was wondering if it even fit with the rest of the visuals.  The first change I briefly played with, before deciding against it, was a white and (surprise) dotted line border.  I decided that it didn't really work, as compared to the rest of the rounded shapes it was very sharp and looked out of place.  This could have been solves by using a rounded square, but since this is the same shape as the bounding boxes of text there may have been confusion with visual hierarchy as both header and body text would have had similar "anchors".   As I spoke about in an earlier blog post, the "step 2/3/4" navigation button will not be staying, as it is distracting text on the page and a small list of numbers in the corner would easily display what stage the user is at in the step-by-step process.


This title was an experiment following a tutorial I did during a slump, but I ended up liking the clean look so much I kept it.  The cross-hatching (also part of the tutorial) adds a bit of a crafty look, which could compliment the stitched look that the white dotted lines lend to some of the diagrams further up the page.   This font is Futura Medium in caps, which is one that you can't really go wrong with.

As in some places the body text was placed quite far apart, linking arrows help literally guide the eye from one step to the next.  The shapes of the arrow complement the circular illustration anchor so I feel at the moment there's a nice movement. 



The header is quite stark compared to the body font, but I feel that at the moment it keeps it quite refined and means that the central components are the illustration and the informative text.