Github | Fiona MacNeill | Macknowlogist

The weekend of doom

Mon, 16 Jan 2017 00:00:00 +0000

In my last entry I talked about the suggestions that Theo provided from his perspective as a nurse and researcher. They were very helpful, but lead to some rather major layout changes. In particular, the to do: “I will need more space in the carousel/timeline”. This led to what I nicknamed in my GitHub posts as the Weekend of Hell, I am softening this within the context of this journal entry to be the Weekend of Doom.

. An image showing how the site looked prior to the changes to the carousel.

Altering the Flickity Carousel/Timeline

So changing the height of the Flickity carousel used for the patient timeline meant that the “dot” buttons had to be moved upwards otherwise they would be off the bottom of the visible area on most standard screen sizes. For reference, I have included a long screenshot that I made of the site prior to this work, on the right. So I decided that the dots should reside on-top of the carousel and then they would also be spatially connected to the navigation of the timeline. This is not really how Flickity carousels are really designed to exist (metafizzy, 2016), but it is closer to the original inspiration for my site the DuckDuckGo about page (DuckDuckGo, 2014). The main issue that I ran into was that the carousel needed to resize itself dynamically and I had media queries which hid the dots on mobile devices (as they were no longer very useful as buttons at that size). However, as the dots themselves are rendered automatically by the JavaScript, they were rendering much more quickly than the resizing. So I upon sizing-up a responsive browser window the dots and timeline appeared on top of everything and looked awful. I tried everything I could think of to fix this issue. I attempted to delay the dots in the JavaScript. I also tried writing a script which watched for the window size. I tried positioning the dots so that they moved upwards. I also tried creating condition code which watched for various conditions to be met prior to triggering the dots. Things I wrote worked to an extent, but not sufficiently or reliably enough to depend on them. In the end I had to temporarily hide the dots by setting them and the timeline to ‘display: none’. I also had to hide the spot where they generated by moving the about section upwards. Essentially the solution’s analogue equivalent is that the rabbit is being hidden in a compartment of the hat the whole time (oh wait…is that how they do it?).

Performance Issues

I am actually grateful that all of this happened as once I had cracked the rendering issue I realised that there were some major performance issues with the carousel/timeline. It took a bit of time to get to the bottom of it, but in the end I realised that it was the long svg that I had included to indicate the patient’s anxiety levels. Through testing in multiple browsers, on Mac, PC and mobile I realised that the image also wasn’t loading anywhere other than in Chrome for Mac. Everywhere it was just gumming up the works. I reassessed the need for the anxiety level gauge/image and decided that it was important to keep it. So through trial and error I ended up loading with an image tag in the html as a very, very long svg. This is the only svg in the site that I could not optimise as it resulted in optimisation errors because it was too long dimensions-wise. Also, I realised that I did not really want to optimise it as I would result in losing the drop shadow detail which I had added to a new version of the design.

The new design

The performance issues highlighted that the design of the patient anxiety-level link was in fact creating an optical illusion and making the carousel look guddery/jerky even once the problems with it were fixed. The new design not only looked more streamlined, but it moved more smoothly simply by virtue of its aesthetics.

Version 1 - This screenshot deliberately shows the progress between two slides. This version of the anxiety level image had a visual effect akin to passing a row of trees with bright light behind them. It became very jarring when viewed at-speed

Version 2: I created a long svg in Adobe Illustrator with a greater level of logic. Attempting to map the story thematically to a graphical interpretation of the patient stress levels. This link is on the one-hand more graph-like but also more oraganic as I made it from scratch by drawing and manipulating a continuous line…Can you tell I went to art school?

Space economy

This entry represents the end of a period where I added a lot of content to the site. This was a good thing, but it also meant that there were areas that felt overly heavy like the devices area. I decided to try adding a collapsible accordion as a container for the information, using a tutorial from Codrops (Mary Lou, 2012). The tutorial was bit old but I liked how it used CSS and I felt that I could build on it. The accordion looked quite nice too, I’m sure that you can sense a ‘but…’ coming on here? Well I will explain it in the next journal entry. I have however included a screenshot the accordion so that it can live on it perpetuity.

. This is where I got to with them. Partially styled, but a nice efficient use of space. I would have added svg “+“s on the right to indicate their interactivity.

The contact form actually works now

I wrote a dev post about the contact form, but yes the contact form is now working as it should. I just need to enhance the warning/alert aspects and add aria labels etc. And so does the back-to-top the button as in it only appears when one is sufficiently far from the top of the page for it to be useful. This took a couple of iterations of code to get right.

Finally…

I had come up with a CSS style for reference sections and I decided to add it to this journal as well as part of my custom child theme. I am going to try (time allowing) to add it to my all my posts retroactively, but it is a big job and I have surprised myself at the sheer number of posts that I have amassed here in the past few months.

References

Coyier, C. (2013, March 5). Using SVG

\[Blog post\]

. Retrieved from

DuckDuckGo. (2014, February 20). About DuckDuckGo. Retrieved January 15, 2017, from DuckDuckGo.com website:

Mary Lou. (2012, February 21). Accordion with CSS3

\[Blog post\]

. Retrieved from

metafizzy. (2016). Options. Retrieved January 15, 2017, from metafizzy website:

Sowmya. (2013). Re: Nesting an svg inside a div

\[Online forum comment\]

. Retrieved from StackOverflow website:

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

Portfolio site concept and other news

Sun, 23 Oct 2016 00:00:00 +0000

Over the past three weeks since the start of the module, I have been working away on the development of my portfolio site concept and gaining domain knowledge to support the development process. I have found myself in a situation where I have been torn between completing the UX procedures and design artefacts that I learned about and implemented during previous modules and starting to code. It is like standing at the edge of an exciting, and slightly daunting, precipice wondering whether to make the leap. The good news is, I am close. I must also at this point, state that I aim to make a real and useful website. It will be short and sweet but it will, hypothetically at least, fulfill a real-world purpose. I also hope that it will be possible to use the site to support future research work that I plan to undertake.

Process: A minimalist approach influenced by LEAN UX

I have found that I cannot bypass the UX design artefacts and documentation entirely as they have become part of the fundamental fabric of my thought processes! So I have decided to complete a very stripped down version, to ensure that I have a solid architectural foundation for what I am about to build. This approach will be composed of the following elements.

A concept document in a bare bones form aka this journal entry!
Task scenarios - is the first version.
Business Model Canvas¹ - an artefact template that I found via Cao & Bank’s, The Guide to UX Design Process & Documentation (n.d.). This will be in a forthcoming journal entry.
General characteristics for user groups - this will also be in a forthcoming journal entry. Due to time contraints and available information, it is not possible to build thorough characteristics lists for all potential users. I am however, fortunate to have a real stakeholder who can provide feedback on my work and it’s hypothetical usefulness. (more on this later on in this entry).
\[Tentative plan\] create a UML² diagram to ensure that each page and section of the site includes the correct information and functions. I personally find UML diagrams to be very helpful for archictectural planning. It can be a fairly basic model for this project, but I do find that the process of making the models uncovers things that you haven’t thought about! I may find that this isn’t needed, but I won’t know until I start making it.
A paper prototype - as I am working with a real stakeholder, I want to show him something quick and easy so that he can visualise the concept and ensure that my representation and approach to the domain is accurate. I think that a paper prototype is the best way to do that, in order to move to the coding phase as quickly as possible.

Concept

The wait is over! Here is the concept. The project’s working title is patient pre-op anxiety infographic. It is a website structured around a central page, which leads the viewer through a fictional narrative of a patient’s experience of anxiety while awaiting a medical operation or procedure. In the narrative the patient will be using an electronic wearable device to track their own vital signs and also for logging their anxiety levels - the influence of this countermeasure will be explored. The narrative is represented through a navigable timeline enriched with the use of graphical, written and statistical information. The underlying project, to use wearable devices to measure patient pre-operative anxiety is attributed to and courtesy of Dr. Theofanis Fotis (School of Health Sciences, University of Brighton), whom I am collaborating with at this time.

Scope

The patient pre-op anxiety infographic will:

deliver an approachable overview of aresearch project - the proposed research project is to design a user interface for a medical wearable device to measure anxiety;
explain the issues that can result from pre-operative stress in patients;
provide a point of entry for those with little or no knowledge of the subject as well as explain the potential benefits of the project to experienced medical professionals.

The patient pre-op anxiety infographic will not:

provide indepth medical information;
provide any fully formed solutions or recommendations for implementation of wearable devices in a medical setting;
provide advice or suggestions for the production of patient care plans. As a narrative scenario it is exploring a hypothetical scenario in which a wearable device is used.

Benefits

The patient pre-op anxiety infographic will provide the following benefits:

it will provide a valuable resource for explaining the research project to potential funders and future stakeholders;
it will help to raise awareness of the potential issues related to patient pre-operative anxiety;
it will highlight potential ways that increased knowledge of a patient’s vital signs and self-reported anxiety could improve patient care;
it will provide an accompanying contextual information for the proposed future interface design project;
it will be a publicity tool, that can be used to explain the project within the academic and medical online communities.

Goals

The following goals are related to the successful creation of the patient pre-op anxiety infographic:

provide a valuable portfolio piece, not only in terms of web development, but also as a tool for the research team and collaborators;
contribute to the approval and ethics approval of this as a concept for F.MacNeill’s final graduating project;
stimulate dialogue around the issues and ideas raised by the patient pre-op anxiety infographic;
encourage potential funders and stakeholders to invest in the project.

Objectives

Create an accurate portrayal of a possible patient care scenario.
Provide information highlighting the benefits of the proposed project.
Pose the project concept as an open question in order to gauge feedback and interest from the medical community and potential funders and/or stakeholders.
The user audiences for this are diverse but have one thing in common, they have very limited time to engage with a website of this kind. This website should take no longer than 10-15mins to navigate, the equivalent of a typical coffee/tea break.
To be shared via social media between interested parties.
To be adaptive and easily viewed and navigated on mobile devices.
To be accessible to those on older web browsers (as far as possible).
To be accessible to users with disabilities, allowing for personal customisation (as far as possible).

The Research Team

Right now this is just me, however Dr. Fotis has agreed to review the materials and my hope is that if the site meets his approval then we will be able to use it to promote the real project. In the first instance it is a hypothetical project site, but that doesn’t mean that you cannot aim high as I have outlined in the objectives above.

Audience

More detail on this in a future entry. The user groups are: funding review panel members, academic staff at multiple Higher Education Institutions (HEIs), medical professionals.

Stakeholders

Intially Dr. Fotis is the main stakeholder, however I would take this site forward as evidence to support my final project proposal. In that sense academic staff in the School of Computing are also future stakeholders.

Research of the domain and existing websites

I have been using my as a place to collect links and resources. On the one hand I have been looking at the specs for potential wearable devices, it is out of scope to suggest an actual solution but I would like to supply some possibilities in terms of device form so that the project is tangible. I have also been reviewing materials that Dr. Fotis provided to help gain domain knowledge of a patient’s pre-operative experience. I have listed these sources in my reference list below.

Sketch of patient journey ideas.

Existing websites

As a general observation medical websites tend to be firmly on the utilitarian end of the scale. This is understandable as information is usually important and needs to be delivered quickly. So it will be important to strike a balance between something eye-catching, which is also substantive. Here is are few examples that I came across and wrote notes about (transferred from my trello board).

Notes/Observations

This . Some of the examples are a bit old and don’t work as well in contemporary browsers. This is something to consider. Most of these sites are in a long-form vertical format. This is great and modern, but considering the audio for this site, this obscures some key aspects of the journey. Viewers will be time-pressured and need to see the journey/timeline elements as succinctly as possible. The following sites are closest to what I want to design:

. This example is not very responsive, so that would be something to consider.
. This blog is quite nice but the scrolling right function would need to be made much more obvious.

Vertical timeline examples:

I like the intro page segment on . It isn’t keyboard navigable though which is not great in terms of my accessibility goals.
and it aesthetically simple and user-friendly.
I quite like , it is text heavy, but it gets the message across quickly.
I like the use of months on the timeline on , although accessibility and control might be an issue here.

Many of these are quite old or have changed format since the post was written. I found myself considering a horizontal layout due to the need to display data and the need for it to be readable, however horizontal layouts pose some real accessibility and navigation issues.

. An oldie, but a goodie …and some justification for my concept!

This site uses the , which I have used many times, mostly in WordPress sites. This is , but I want something a bit more contemporary.

This site has the kind of section feel that I am looking for, although I still wonder how I can visualise anxiety in a vertical layout versus horizontal. [This site](( ) has nice comment mark-up and makes clear use of the
element.

Journal development

A quick run down of learning journal development activities. A full rundown can be found on my github development page, I have added a handy link to to this in the “social menu” on the right-hand footer of this journal site (circular icon with octo-cat logo).

Created an iframe embed in a widget for my trello board so that I can display it in the sidebar. In order to create this I referred to this example on and . Tomorrow I am attending a in Brighton and as part of the event they will offer user testing. I thought why not add some functionality that I have always wanted to include AND get some tips.

I have added the option for visitors to this site to change the colour of the background (behind the text) for accessibility reasons. I did this as by creating alternate child-theme style sheet and by installing the . This idea is inspired by software like of Adobe Acrobat Pro and GoodReader App (for iPad) which allow you to customise background colours. I referenced for colour-palette inspiration. Visual stress when reading and/or perception of colour contrast are reasons why a user might wish to alter background colours.

hexidecimal colours used for initial function:
- blue 1: #dfeced
- blue 2: #9ab8fc
- green 1: #a6f8e3
- green 2: #aaf2a0
- yellow 1: #ffff8f
- yellow 2: #ffde75
- purple: #bf95df

I’ll write about any resulting feedback and actions on this site later. I added Google Analytics code to my version of the header.php file, this was not added to GitHub as it is specific to my version of the child theme. I decided against a plugin as I looked at a couple of options, but I didn’t feel that having access to a Google Analytics data on the dashboard of WordPress was that important as compared to the account authorisation that plugins require to run (e.g. that I looked at). I like to keep an eye on web traffic for security and publicity reasons.

Coding practice

I have a Lynda.com course to wrap-up and I will post the details here when I finish. In the meantime, collectively I have now completed 200 exercises in Code Academy! I didn’t do them all since the start of this module, but here is a screenshot of my badge

Just putting this here for later reference - found on my travels

10 Commandments of User Interface Design

]( ) Courtesy of:

References

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

Gothelf, J. (2013). Lean UX: Applying Lean Principles to Improve User Experience (1st ed.). United States: O’Reilly Media, Inc, USA.

Prichard, M. J. (2009). Identifying and assessing anxiety in pre-operative patients. _Nursing Standard 23(_51), 25-40. Retrieved from

What can help relieve anxiety before surgery? (2014, May 21). In PubMed Health. Retrieved October 15, 2016, from

Business Model Canvas ( ), licensed under Creative Commons Attribution-Share Alike 3.0 Unported licenses ( ). ↩︎
Unified Modeling Language - more information at wikipedia: . ↩︎

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,

Github | Fiona MacNeill | Macknowlogist

The weekend of doom

The new design

Space economy

The contact form actually works now

Finally…

References

Business Model Canvas and more tweaks

More to come on the to-do list:

References

Portfolio site concept and other news

Process: A minimalist approach influenced by LEAN UX

Concept

Scope

Benefits

Goals

Objectives

The Research Team

Audience

Stakeholders

Research of the domain and existing websites

Existing websites

Notes/Observations

Journal development

Coding practice

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