Javascript | Fiona MacNeill | Macknowlogist

Cellular concerns

Sun, 11 Dec 2016 00:00:00 +0000

I have been plugging away at the portfolio site with the primary aim of getting a semi-functional prototype version to Dr. Theo Fotis on Monday 12th of December. There is a still a huge amount of stuff to do, fix-up and streamline I will add these tasks to my Trello board. This journal entry provides a rundown of the decisions that I have this week.

Flickity carousel

I decided to make the carousel-cell 100% width due to the need for a more immersive timeline. What I mean by this is that I felt that the cells were too modular before and the greater width (formerly 66%) makes more sense in terms of showing the long anxiety levels .svg file. I still have lot of work to do in terms of consolidating my JavaScript and CSS files into one of each and then also minimising my JavaScript file. One of the things that Marcus brought to my attention was that my script sources should not be loaded in the header of my index.html and that this was bad practice. They now reside under the footer, but this presented some new challenges. For example the smoothScroll function had issues loading so I added a new main.js file (this is will become the final master js file) and added a window EventListener and then added an init function - to initialise SmoothScroll after the load is completed. The other issue is that Flickity Carousel for the timeline started to flash up momentarily as a column until it found it’s brain (aka the script actually loaded). I actually only discovered this due to using my mobile broadband stick in a cafe and noticed the latency. The Flickity Carousel is currently initialized at the bottom of a unique flickity.js fileI needed to keep the smoothScroll.js and flickity.js separated while I figured out how to get things working harmoniously.. What I needed to do to solve this was to set the carousel opacity as 0 until the window has loaded and as the carousel is not a function in the same way as smoothScroll it was a bit trickier for me; there wasn’t something straightforward for me to work with. What I ended up doing was adding a new variable for carousel immediately after initialising flickity (entails designating the css selector as a flickity carousel) and then applying a style to make the opacity 1I had to consult github for help with this as I was at a loss for a bit: .. This is working nicely, however the delay or a white screen may be improved by a momentary loading GIF in order to explain what is going on for a slower connection - one to add to the to do list! I quite like the Buffer GIF animation and this helpful tutorial explains how to code something like this with an SVG file as opposed to GIF, I’ll give it a go: . Also due to the audience of this site, I think that it is important to include the word “Loading” alongside any GIF or animated SVG. As part of the process above I added the cellSelector option to the carousel in JSON format, as initially I thought that I might want an EventListener. It seems that this might be useful later on, so I have left it in place for now. e.g. data-flickity='{ "cellSelector": ".carousel-cell", "freeScroll": true}' Another issue was with the customised Flickity dots (used for timeline navigation) was that I had set the position of their container to absolute and the overflow to hidden as a solution for smaller screens or browser windows (the dots disappear entirely on a mobile phone sized screen). However, I noticed a sort of ghosting issue as a consequence of the overflow.

[

] It is quite subtle, but can you see those little grey lines between 2 and 3 and also between 3 and 4? There be the ghosties! I fixed this by adding “white-space: nowrap;” to the dots themselves so that the wrapping was disabled. Result!

. Yay, no more ghosties!

Here be the stuff of nightmares…

I have to admit that I spent way too much time on this issue, but it was honestly driving me to distraction. So having fixed my grid so that it was had even widths and looked lovely as I started to use my grids I found that I needed to add unique classes for the blocks that appear in each

of the html file. The grid structure is left in place as a logical point of reference. Then I found that my written content in the grid was overflowing beyond the height of the sections. This was relatively easy to fix by setting the classes for the sections to have relative positions and have overflow set to auto. Phew. However, as I added some placeholder content to my grid blocks I found that the widths were still perfect but the heights of columns were not okay. What I mean by “not okay” is that if a block had more written content then it was longer to contain this content. Therefore blocks positioned adjacent to each other looked askew.

/* tried this and hated it .is-table-row { display: table; } .is-table-row [class*="col-"] { float: none; display: table-cell; vertical-align: top; border: solid 7px #EEEEEE; border-radius: 0; } */

This was strangely very hard to fix. I tried several methods. First I tried fool it into thinking it was a table, but I lost my gutter and I worried about responsive accessibility. I also tried CSS pseudo classes (which I now have a little bit of experience with after customising the dots), but it didn’t provide the desired look either. I also tried adding attributes to the section container and the “One True Layout Method” (Coyier, 2010) where the margin-bottom is set to -99999px and the padding-bottom is set to 99999px and the overflow is hidden. This feels like brushing the problem under the carpet and it looks like it too as it cut off the bottom of my block outline and I like the outline. In the end I used row class for my grid defined to display flex and and then use the flex-wrap wrap setting. Alas, with one fell swoop my dream of full functionality in Internet Explorer is dashed as Flexible Box Layout module is not supported in IE9 at all ( ).

In an earlier journal entry I had cited this fixed navigation example on codepen ( ) as being close to what I would like for the navigation on my site, however I have also been devouring a book on web accessibility, Inclusive Design Patterns Coding Accessibility Into Web Design and anything fixed in the CSS was identified as a no-no in the book (Pickering, 2016). I had also found that the fixed header height meant was causing issues with the distance of the smoothScroll function. I was able to fix this by checking their documentation and adding the labeling the header as data-scroll-header and then specifying this in the initiation script. Previously I had defined a spacer div for this purpose, it didn’t work perfectly for the smoothScroll function, but it ended up being handy for defining white space between the timeline and the about area (in addition to the use of margin settings it was helpful to have something that was independent). In the end I didn’t need most of this work as due to the advice in Pickering’s book, I decided that the navigation header needed to have a relative position instead of being fixed.

Anxiety levels

As I mentioned at the beginning of this post, I wanted to give the carousel/timeline a long image that continued along the base of cells showing the anxiety levels of the fictional patient during the story (this was shown in ). I started by testing with a .png image and as I anticipated it looked awful but I was most interested in getting the positioning setup correctly. The issue was that the image kept showing up above or in front of the text inside the description div. Also as the window was resized the image floated upward from its initial position. The only way that I could fix this was to use z-index and a fixed position for the image container (I already broke the rules about fixed items - see above) and then added a unique style id called #anxiety to specify how my image was shown in the container (as a background image). Initially I thought that I might need to specify one strip of the image per cell in the Flickity, but they kept overlapping and having layering issues. The logical approach in the end is to have one very long SVG. I need to optimise the SVG prior to the final release of the site, but at the moment I am still adding to it in Adobe Illustrator as I need to finish writing the patient story prior to finalising the graphic. As this graphic only serves an aesthetic purpose I think it is alright that it is both fixed and defined as a background image (and therefore cannot have an alt tag applied for accessibility reasons).

Bios section

I added box-shading to the photos - they needed a little something to differentiate them against the background. Once again this is not supported in IE9 although it is less critical than the flex-box issue outlined above.

Responsive adjustments

I worked on the mobile phone break point for the media queries first. Specifically, @media (max-width: 414px) I based this size on the Google Nexus 6P and the Apple iPhone 6 plus as although these are both phablet sized I certainly need the grid blocks to be shown in a single column at this size not in rows. In general I would like to steer clear of too many device specific breakpoints as it is better to think about the legibility of the design rather than get too obsessed this (an article by Justin Avery (2013) supports this view: - not everyone agrees on this). Also, I realise that I need to go through the code and consolidate my classes and ensure that my units are standardised as % and em prior to doing too much work on this. So the rest of the styling and layout needs to be completed first, based on a desktop first mentality.

Thinking about the patient

I found myself rethinking the fictional patient’s name, based on the ever helpful Wolfram Alpha. It seems that women named Ruth are demographically older than the fictional patient should be (roughly 55-65yrs although I need more data on this - more on this in my next post). Although Wolfram Alpha is based on demographic information from the United States it is a good basic litmus test for this. Here is my comparison, Carol may be a better name:

References

Avery, J. (2014, October 28). Why you don’t need device specific breakpoints. Retrieved December 11, 2016, from Background-repeat. (2016, December 3). Retrieved December 11, 2016, from Background-size. (2016, December 3). Retrieved December 11, 2016, from Blender. (2016). Force a div to contain floated child divs. Retrieved 11 December 2016, from Bos, B., Etemad, E. J., & Kemper, B. (2014, September 9). CSS backgrounds and borders module level 3. Retrieved December 11, 2016, from Box-shadow. Retrieved December 11, 2016, from Can I use… Support tables for HTML5, CSS3, etc. (2016, October 23). Retrieved December 11, 2016, from cferdinandi. (2016, December 11). Cferdinandi/smooth-scroll. Retrieved December 11, 2016, from Cope, S. (2011a, September 6). Z-index. Retrieved December 11, 2016, from Cope, S. (2011b, September 6). White-space. Retrieved December 11, 2016, from Coyier, C. (2010, October 8). Media queries for standard devices. Retrieved December 11, 2016, from Danilo, A. Splash vector graphics on your responsive site. Retrieved December 11, 2016, from Kraken.io image Optimizer. (2013). Retrieved December 11, 2016, from LePage, P. (2016, December 16). Responsive web design patterns. Retrieved December 16, 2016, from Lumsden, A. (2012, June 27). Getting started with Scalable vector graphics (SVG). Retrieved December 11, 2016, from metafizzy. (2016). Callback when Flickity is initialized? · issue #269 · metafizzy/flickity. Retrieved December 11, 2016, from metafizzy. Options. Retrieved December 11, 2016, from

Pickering, H. (2016). Inclusive design patterns (Kindle ed.). Freiburg, Germany: Smashing Magazine GmbH.

Quick and simple image placeholders. Retrieved December 11, 2016 (UPDATED: May 5, 2019), from Salloum, N. (2014, April 4). CSS equal height columns, Three different ways. Retrieved December 11, 2016, from van Gemert, V. (2013, March 1). Logical Breakpoints for your responsive design – smashing magazine. Retrieved December 12, 2016, from Design,

Progress on the grid and layout

Thu, 08 Dec 2016 00:00:00 +0000

This week I completed some major fix-up on my grid. Remember when I thought that it was almost fixed? Well I was wrong. In fact I ended up recalculating the whole thing and basing it on a single column being 65px or 6.5% in width. Happily it is now working exactly as I need it to (Mozilla Developer Network saved the day again - I am going to up my donation this year).

I am feeling griddy

Now that my grid is in situ, I am able to base layout elements on it. I do think that in most cases I will need to make unique versions of the columns and tweak the row layout, but keeping the grid architecture in place and temporarily adding the rows/columns to the html has been really helpful for planning out the sections (as shown in the screenshot below). I used my grid to start planning the layout of the content on the Flickity carousel cells - as it turns out this took quite a bit of work (more on that in my next post). I also had my first go at creating an SVG, albeit a very simple one as a placeholder for the first cell in the carousel. The SVG shows the outline of a head and I made it in Adobe Illustrator, this will need to be replaced by more of a photographic image for needs of the project.

about-About

Adding in an About section as the timeline really jumps right into talking about the fictional Patient. I will need to update the to reflect this, but it remains within the bounds of the tasks as task scenario 1 included, “Read introductory information”, this needs to become task scenario 2 and the others need to be bumped up. I also need to revise things where they are areas as opposed to pages, it is bit too specific at the moment.

Testing in Internet Explorer 9

I was astounded to find that pretty much everything on the site is working as one would expect in Internet Explorer 9. This is fantastic and vindicates some of the script selections that I have made in terms of browser support. I was very concerned that the z-index settings would not be respected, but thus far it is looking good. Safari is still a problem though…

Screenshot of the site on 9/12 shown side-by-side in IE9 and Chrome. I am now kicking my myself for not recording the exact browser version numbers on the PC I was using at the time! The majority of my day-to-day testing takes place on a variety of Mac, so I have to check on Windows whenever the opportunity presents.

Toying with the notion of animation

One of the sites that I have mentioned before, has some pretty gorgeous and playful animations on it. I took a look through the code and the javascript attributes and most of it is managed via CSS. This is good, although I would am concerned about browser support and also performance rendering. As a consequence I probably won’t add these features. As a pre-check I used the Chrome timeline tool to record the processes on an older computer that I have at home and I felt that the impact on performance would be a problem the new features operate at the limits of what I want, timing-wise so I will need to see if I can optimise them further. I have already removed aspects of the code that is not used..

References

Basques, K. (2016, December 8). How to use the Timeline tool. Retrieved December 8, 2016, from Common CSS questions. (2015, October 26). Retrieved December 8, 2016, from daneden. (2016, September 27). Daneden/animate.Css. Retrieved December 8, 2016, from Grids. (2016, October 7). Retrieved December 8, 2016, from Lewis, P. (2016, December 8). Rendering performance. Retrieved December 8, 2016, from SVG and CSS. (2016, January 2). Retrieved December 8, 2016, from Z-index. (2016, December 2). Retrieved December 8, 2016, from

Timeline tool identified

Fri, 25 Nov 2016 00:00:00 +0000

After a lot of consideration, struggle and annoyance I finally gave in and decided to use a pre-existing tool for the timeline section of my front page. I looked a few different contenders in this final pass. Essentially, I came to the realisation that I would not be able to learn the requisite Javascript in order to build something sophisticated enough from scratch. I did a bit of trying out in this jsFiddle project, but kept running into deadends (this project is in a partially built state - so please do not judge me - the javascript is largely erased by this point): Initially I found only jQuery examples - but as I have previously stated, I really wanted to work with Vanilla Javascript, due to load times, future proofing the code content. I also feel that it will be more beneficial to my learning to stick to learning Vanilla Javascript (or rather Ecmascript 6) so that I truly get the language prior to becoming too invested in specific frameworks. Also having looked at these two resources: and then the From - vanilla makes much more sense to me.

jQuery example 1: horizontal timeline ( | )
jQuery example 2: vertical timeline ( | )

After looking at these and searching quite a bit, I came across a tool called lory ( ). It is essentially a code package or widget for creating interactive slideshows or gallery. I thought that there might be some milleage in creating a slideshow or gallery and somehow customising it as a timeline. After testing I found that lory also was overly complex for my needs. Then I came across a really helpful article about a widget tool called on css-tricks.com ( ). It was love at first sight! Here is an example on codepen showing how the Flickity slideshow originally looked: - Flickity is both responsive and touch optimised and had a vanilla option in addition to jQuery. It seemed like a good solution. Before my modifications:

After my modifications:

Main modifications were: - the timeline-line- size of slides - outlines for references - big dots on the timeline (need to figure out how to label these) - overflow to ensure that the content doesn’t wrap strangely on a mobile device. There is still a lot to do and I need to fix an issue when the keyboard keys, when used for navigation make the web page scroll-right in a strange way. I also need to unite this with the other parts of the page that I have started to build. Finally, Flickity is a paid solution unless it is used under a . I am passionate about open source and was already licensing my work under an so I have decided to set the rest of my project to . This means that the license information needs to be included in the header of each source file. As the portfolio site will not contain any original research and will only provide an overview of the project this will also comply with the University’s Intellectual Property rulesAs a student and employee I need to be aware of the university’s Intellectual Property rules, which are available here: . However as portfolio site will not provide software with potential for commercial value and the project information itself is in the early stages it complies with the rules.. Also in the markup of the html, CSS and Javascript I have indicated where pieces of code have come from and if/when licenses apply. Update: Shortly after writing this post I solved the issues outlined above (see: “There is still a lot to do…”) and these discoveries are outlined in the next couple of posts. I realise that I forgot to mention how I solved the issue of the number labels on the dots below the Flickity carousel. This problem turned out to offer me a very valuable lesson in the . I have used the former, “before::” as this was introduced in CSS3 and is compatible with IE9 based on my testing. I figured out that the dots themselves could be used as a counter-increment for the addition of the number labels. .dot { position: relative; overflow: hidden; display: inline-block; width: 40px; height: 40px; margin: 0 20px; background: #a9a9a9; border-radius: 50%; cursor: pointer; counter-increment: flickity-page-dots; } .dot::before { display: block; text-align: center; content: counter(flickity-page-dots); padding-top: 11px; font-size: 20px; color: #FFF; } As the dots themselves are automatically produced by the Flickity Javascript, this meant that my number labels were now produced too. A nice solution.

References

Coyier, C. (2015, March 5). Creating responsive, touch-friendly carousels with Flickity

\[Blog post\]

. Retrieved from Flickity - freeScroll. Retrieved November 26, 2016, from Flickity License. Retrieved November 26, 2016, from Flickity. Retrieved November 26, 2016, from Free Software Foundation. (2007). GNU General Public License. Retrieved November 26, 2016, from Heinz, M. (2015). Lory minimalistic slider. Retrieved November 26, 2016, from Horizontal Timeline in CSS and jQuery. (2014, February 28). Retrieved November 26, 2016, from Mozilla Developer Network. (2016, July 24). :Before (:Before). Retrieved November 26, 2016, from Open Source Initiative. The MIT license. Retrieved November 26, 2016, from Saunders, S. Intellectual property (IP). Retrieved January 4, 2017, from Vanilla JS vs jQuery. (2017). Gist. Retrieved 26 November 2016, from Vertical Timeline. (2014, June 12). Retrieved November 16, 2016, from Way, J. (2012, January 19). From jQuery to JavaScript: A reference. Retrieved November 26, 2016, 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,

Javascript | Fiona MacNeill | Macknowlogist

Cellular concerns

Flickity carousel

Here be the stuff of nightmares…

SmoothScroll and the Navigation

Anxiety levels

Bios section

Responsive adjustments

Thinking about the patient

References

Progress on the grid and layout

I am feeling griddy

about-About

Testing in Internet Explorer 9

Toying with the notion of animation

References

Timeline tool identified

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