Business Model Canvas and more tweaks

Sun, 06 Nov 2016 00:00:00 +0000

A shorter journal entry for today. I am going to provide a brief outline of what I have been working on, as I need to crack on with planning materials and more development work this week.

I have completed an initial version of the Lean Business Model Canvas, as mentioned referencing UX documentation and design artefacts. I obtained the template recommendation in Cao & Bank’s (n.d.) book on UX documentation.
I have asked my friend Jason to take a look at my code for the arrow button navigation, so I will work on some more tweaks to that tomorrow.
Due to extremely limited time this week as a result of some unanticipated work commitments, I haven’t got as much development work in as I would like. So I have focused on a few fixes on this site as they were smaller thinks that I could achieve in the time that I had.
- I removed a superfluous hyperlink in the footer.php - it was a copy and paste mistake.
- I decided not to “provide a choice of fonts” as it felt like it might offer too many options.
- I decided to install the - I have worked with it before and found it to be one of the best plugins in this area. It offers user-facing tools and some javascript additions to fix common issues in WordPress. Even though I have an accessibility tagged theme, there are additional tweaks that can be completed such as removing title attributes in areas where they aren’t needed and enforcing alt tags. It also allows you to add an active link highlight, which I am initially trying out with a contrast tested purple colour (essentially it puts a box around any active element).
- I worked on a few customisations of the plugin:
  - I added it to a sidebar widget instead of the toolbar that is typically used with the plugin. This is mainly due to some issue with the display of the toolbar and also it made sense to present the accessibility options above the background colour options.
  - I customised the font-family and font-size of the text in the accessibility widget.
  - I enabled the high-contrast and font-size (large text) options as part of the WP Accessibility Plugin.
  - I customised aspects of the large text display so that it worked better with the theme, initially some text was too and some was too small. For example, H2 was a too small in comparison to the paragraph text and stylistically and readability-wise it wasn’t great.
I also changed the text-transform settings on the widgets header text as I noticed that these were all uppercase. This is not the best for Dyslexic readers according to Gov.uk’s recent accessibility posters ( ). I find this series of posters to be very helpful cheat-sheets for accessible design.
- Related findings:
  - Gov.uk Accessible Blog:
  - Gov.uk Government Digital Service:
  - Gov.uk Advisory:
Also in my travels I found the Web Accessibility Evaluation Tool (WAVE) - this was recommended both by the WP Accessibility Plugin authors in the documentation and on the Gov.uk page above on the “making your service accessible” page.
The report (although it will change as the site is being updated) WAVE highlighted some more bits that I need to work on and I do still need to look at the contrast of the text in comparison to the background in the different colour schemes. The “making your service accessible” page states that automatic tools like WAVE can only detect a proportion of issues (around 20%-30%: ). So I need to ensure that I don’t regard these tests as exhaustive moving forward.

I feel that I have learned quite a bit about accessibility through my work on this journal site, as well as honing my existing skills. So I will take these ideas and techniques forward with me as I continue to work on my portfolio project.

More to come on the to-do list:

concept document
Task scenarios
Business Model Canvas
General characteristics for user groups
\[Tentative plan\] create a UML2 diagram
A paper prototype – the prototype may actually need to be made in a prototyping tool so that Theo and I can discuss it via email. So probably a change of plan on this one.

References

Cao, J. & Bank, C. (n.d.). The guide to UX design & documentation process. Retrieved from

Theme testing

Thu, 13 Oct 2016 00:00:00 +0000

This journal entry continues on from my first post. In that section I outlined plans to test a number of WordPress themes that had been tagged with accessibility. This led me down a fascinating path of learning with one wrong turn along the way.

The testing process

In my last post I outlined a number of themes that looked like possible candidates, including the following:

(WordPress core theme)
(WordPress core theme)

As part of the testing plan I used a several tools, listed at the bottom of this post, to analyse the best themes. Please note, that some themes did not reach the full testing phase due to issues that I would term as deal breakers; the issues identified were troublesome enough where it was not worth continuing with those themes. I also entered into this testing process with an intention to attain a WCAG 2.0 Level AA (W3C, 2016a) accessibility rating for my journal site. This is largely because accessibility is a budding specialism of mine and I wanted an excuse to delve around in the innards of the newest WordPress themes!

Testing results and observations

I decided not to install this theme. Although ‘afterlight’ had the accessibility tag, I found on inspection of its specifications that it is based on having a background image throughout each area of its architecture (landing page, pages, posts - all had to have a single background image). Upon previewing this with my content, using the WordPress theme preview tool, I found that this negatively impacted readability. As the purpose of this blog is to engage in reflection, it seems important not to distract from that at the design level.
This theme has (or rather had) a lot of potential and is coded according to best practice (e.g. accessibility tagging) outlined in the WordPress Accessibility Handbook (WordPress.org, 2014).

I realised later on looking at in-code documentation that this theme is based on a starter theme, Underscores (or “_s”). A bare bones CSS starter theme (Underscores, 2016).

Unfortunately after venturing as far as creating a child theme, I found issues in the some of the front-page template functionality. I also discovered that the links through to the theme documentation were broken and as a result I decided cease using the theme.
I do like the clean lines and simplicity of enigma, even in light of the negative points outlined in the slideshow below, it is certainly a worthy candidate. However, the dependence on the burger-style menu (the three lines) although often essential on mobile versions of a site, is less effective when viewed in a conventional web browser. I decided to seek out a theme that offered more versatility for delivery of the navigation menu/s.
Initially I really liked the simplicity of this theme design and it is very responsive, however in terms of accessibility it has some problems. Namely, it does not support reader view in Firefox 49 or Safari 10 and also was not good in terms of respecting the heading levels for the screen reader. I did not complete the other tests as these two issues were deal breakers.
The ultimate in clean and simple. Although as a seasoned WordPress user the annual core template always looks like the annual core template, even with customisation. Twentyfifteen is quite book-like in its bi-fold layout and this doesn’t strike the desired tone. As I tend to be quite verbose in my writing, I think that a theme with better except support is better. Having said that, the core templates can provide excellent bases for creation of child themes.
A fresh approach to a traditional blog layout with some very nice built-in features. Highlights include the support of the read more tag for determining the length of post/entry excerpts shown on the front page. I also like the presentation of the author avatar, together with post tags on the left-hand side of each post. This theme has good customisation options and good widget support (the tools that you can place in the aside-style columns in the layout). A solid theme, not the most riveting to look at, but it ticks all of my accessibility boxes!

The final two contenders

I ran an IDI web accessibility check and used Firefox accessibility checker plugin to enable keyboard control on the two top candidates: twentysixteen and chuchadon. Twentysixteen had two flagged elements when I looked at the posts page specifically - one was that h1 header element was nested, so the order of headers was not ideal. Also there was a missing label element in the search field. These would both be very easy fixes.

Chuchadon had the same flag on the header nesting for a posts page, so it is likely that this is an issue that would be picked up for a number of WordPress based blog template. To test this theory I tested my own blog, which is based on the Edublogs implementation of WordPress. Interestingly this was not an issue on my blog (e.g. post: ) or another Edublog that I tried. I took a look at the .entry-title tag in the edublog and it was at h2 level rather than h1. This struck me as an issue with both these themes. So I created a child theme of Chuchadon to try out a tweak on line 353 of the CSS stylesheet. The tweak worked perfectly, but alas this was also when I realised that there were some other things that didn’t work for me in chuchadon (front-page configuration and the documentation links).

The final verdict

I have selected twentysixteen as my theme and have created a child theme to allow more space for customisation.

Image source: WordPress.org,
(Worpress.org, 2016b)

Just to clarify… You may be asking, what is all this talk of child themes. Well in essence a child theme is augmented version of it’s original parent. Essentially a child theme allows you to commit edits to the visual presentation as well as the functions of a WordPress site without editing the original theme’s code. This is a smart tactic for customising a theme, particularly the core annual themes, as because WordPress as a CMS has frequent updates, any accompanying parent theme updates can be safely run without affecting the code in the child theme too much. The use of a child theme will also allow me to replace the parts of the CSS and theme functions that were identified in the IDI accessibility report.

Techie stuff

The server was down this weekend so I used this as an excuse to implement some technical tools which will help further down the line. First of all as I mentioned in my last entry I installed MAMP on my development computer. MAMP, stands for Macintosh, Apache, MySQL, PHP (“MAMP”, 2016) and allows to setup a local copy of WordPress on your computer. I find having access to a local installation to be helpful for two reasons:

I can work on my child theme tweaks without having access to the server and test them out in a controlled environment.
I can test out themes and plugins without muddying my installation. Sometimes everything about a plugin can look good and then you install it and there are things are about it that don’t work or the coding isn’t up to scratch. So again it is good to have a test environment for that.

I also setup a github repository for version control; to track my changes to the theme files. This is the first time that I have setup my own repository, so it was definitely a learning curve for me. However, I think that knowing how to do this will be essential for my forthcoming work on my web portfolio project.

Thinking long and hard about plugin installation is a good idea… I was right to spend time deliberating about the types of plugin to install. The problem with plugins is that you often have to spend time tweaking them for every update and every theme. My carefully considered decision to install the footnotes plugin has already had to result in CSS tweaksWhy not use a footnote to explain what I did! I changed .footnote\_plugin\_text to change the width of the area where the footnotes are shown and the font size. I also had to make the table border elements transparent in the .footnote\_plugin\_link, .footnote\_plugin\_index. Finally I needed to manually change the position of the superscript figures as I wasn’t happy with the distance of the figure numbers from the text characters, for this I changed the .footnote\_plugin\_tooltip\_text class due to how the footnotes were shown in the twentysixteen theme.

Analysis tools used:

IDI Web Accessibility checker (AChecker, 2011).
Snook colour contrast checker (Snook, 2015).
Sim Daltonism colour blindness simulator (Wickline, 2000).
Accessibility evaluation toolbar by John Gunderson (Gunderson, 2011).
Apple and Firefox text-to-speech tools.
Keyboard-only navigation of site.

Guidelines used and referred to:

Web Content Accessibility Guidelines (WCAG) (W3C, 2016a).
Techniques for WCAG 2.0 (W3C, 2016b).
BBC Future Media Standards and Guidelines (BBC, 2008).
Mozilla Developer Network documentation (Mozilla, 2016).
WordPress Accessibility Handbook (WordPress.org, 2014):
- Specifically I found this page very helpful - Questions to ask - The ‘questions’ are derived from the four principles of WCAG and they are immensely helpful.

Software and developer tools used:

MAMP (appsolute GmbH, 2016).
Github - version control and code repository (GitHub, 2016).
WebStorm - editor: (JetBrains, 2016).
Textwrangler (Bare Bones Software, 2016).
Chrome developer tools (Google, 2016).

References

AChecker. (2011). IDI web accessibility checker: Web accessibility checker. Retrieved October 7, 2016, from AChecker website,

appsolute GmbH. (2016). MAMP & MAMP PRO. Retrieved October 7, 2016, from MAMP website,

Automattic. (2015, October 7). Afterlight. Retrieved October 7, 2016, from Wordpress.org website,

Bare Bones Software. (2016). Bare bones software. Retrieved October 13, 2016, from

BBC. (2008, June 24). Future media standards & guidelines - accessibility guidelines v2.0. Retrieved October 7, 2016, from BBC website,

GitHub. (2016). Build software better, together. Retrieved October 13, 2016, from

Google. (2016). Chrome DevTools overview - Google chrome. Retrieved October 13, 2016, from

Gunderson, J. (2011, August 19). Accessibility evaluation Toolbar. Retrieved October 13, 2016, from

Herbert, C. (2016, October 8). Where does “hello world” come from? [Online forum comment]. Retrieved from StackOverflow website:

JetBrains. (2016). WebStorm: The smartest JavaScript IDE. Retrieved October 13, 2016, from

Keijonen, S. (2016a, September 16). Chuchadon. Retrieved October 7, 2016, from WordPress.org website,

Keijonen, S. (2016b, December 29). Kuorinka. Retrieved October 7, 2016, from WordPress.org website,

Lüken, A. (2015, October 31). E.Nigma 2015. Retrieved October 7, 2016, from WordPress.org website,

MacNeill, F. (2016, June 14). [Talk] factors of trust in IoT App interfaces Redux [Blog post].

Mozilla. (2016). Mozilla developer network. Retrieved October 13, 2016, from

MAMP. (2016, September 29). In Wikipedia. Retrieved October 16, 2016 from

Rietveld, R. (2016, March 21). WordPress goes WCAG [Blog post]. Retrieved from

Snook. (2015, January 11). Snook colour contrast checker. Retrieved October 13, 2016, from Snook.ca website,

Underscores. (2016). Retrieved October 7, 2016, from Underscores website,

W3C. (2016a). How to Meet WCAG 2.0. Retrieved October 13, 2016, from W3C Web Accessibility Initiative website,

W3C. (2016b). Techniques for WCAG 2.0. Retrieved October 13, 2016, from W3C Working Group website,

Wickline, M. (2000). Sim Daltonism for Mac. Retrieved October 13, 2016, from

WordPress.org. (2014, October 11). Accessibility handbook. Retrieved October 7, 2016, from WordPress.org website,

WordPress.org. (2016a, December 6). Twenty Fifteen. Retrieved October 7, 2016, from WordPress.org website,

WordPress.org. (2016b, December 6). Twenty Sixteen. Retrieved October 7, 2016, from Wordpress.org website,

Plugins | Fiona MacNeill | Macknowlogist

Business Model Canvas and more tweaks

More to come on the to-do list:

References

Theme testing

The testing process

Testing results and observations

The final two contenders

The final verdict

Techie stuff

Analysis tools used:

Guidelines used and referred to:

Software and developer tools used:

References