A couple of posts back I outlined some grand plans in terms of UX design documentation and artefacts that I am planning to put together. Don’t worry I haven’t forgotten about these things, but they are having to happen gradually alongside my formative code learning and experimentation, so they will be attached to future entries.
One thing I have learned from working in IT for 7+ years is that it is best not to say what you will build until you know what you can build. Sometimes this is knowing the right people who can build it for you, sometimes this is knowing the right tools to use in order to build. With this in-mind I decided to use a long weekend off work to create some coding prototypes to check if what I was envisioning in my mind is actually possible. This is completely opposite of what I would do with UX where I design the interface first without getting too attached to a specific technology. This is okay, but there is value in understanding what can be achieved, especially as I am doing it all myself!
My first prototype was a simple site based on the html5 <section> element<fn>Learned about this from pp. 18-19 and p.54 of the Introducing HTML 5 book (Lawson & Sharp, 2012).</fn>. My thought was that in a later iteration it would resemble something like this site: http://www.akita.co.uk/computing-history/ where container <div>s are added to the sections in order to align written and image-based content. I started by using header level ID tags as anchors for navigation through the content and then used the “tabindex” to determine navigation with the tab key. This prototype was fine, but I felt immediately frustrated by the jerkiness of the navigation; this would certainly take away from the experience of reading the content.
Having said all this, I am pretty happy with prototype 2 as a starting point and I feel that it can provide the structure needed for the next steps. So NOW I am ready to do more on wireframing and possibly physical prototyping.
As a start for the creation of these prototypes I used the HTML5 Boilerplate that is available on GitHub. It seemed like a good way of familiarising myself with all the parts that would be needed for a fully fledged HTML5 application. There are many template parts that I will likely discard, but it was certainly helpful to start this way and it provided a logical filing structure.
My new GitHub repository specifically for the portfolio project can be found here: https://github.com/FionaMacNeill/portfolioproj
I also added a Normalize.css file based on this template from GitHub: https://necolas.github.io/normalize.css/5.0.0/normalize.css
Based on Marcus’s session this week, it is a good idea to include a normalize.css file as it standardises the browsers’ built-in interpretation of styles.
I asked Marcus for some advice on the background colour changing widget (aka stylesheet switcher) and he felt that loading images for the colour-change buttons added to the processing load. I tried a few things in the MAMP version of this journal on my development computer, including changing the images to 1 pixel and then also trying to create buttons that could just be a colour and not a jpeg or png image file. None of these things worked well and I came to the conclusion that as I am working with a plugin and some of these tweaks broke the plugin, I just need to handle the plugin’s limitations. As I don’t have enough time to build my own plugin, I decided to made the images small and simple at 20px x 20px and then altered the stylesheet to make the layout more uniform so that they fit into the sidebar widget better and are shown in a row at most browser window sizes (the widget disappears at phone screen size, this is intentional in the Twentysixteen parent theme, to avoid clutter).
In addition, I added a piece of loading script at the top of each colour-option CSS file as I need each one to load the child theme’s CSS, so that I don’t need to make changes to all of the CSS files, only the main child theme version. I mapped the stylesheet switcher plugin’s php to look in the “css” folder, but I also found that the main child style.css file needed to live in the root folder in order to operate properly (thank you Google Chrome console for highlighting this issue!).
A further development for the stylesheet switcher will be to look at the default hyperlink colours in relation to each background. This includes their active, inactive and visited states as the contrast in relation to the background colour needs to be readable for each colour.
- do I want to provide a choice of fonts and if so, would I provide that function via a different plugin?
- I should look at installing the accessibility plugin and investigating the best settings.
It struck me that I am adding a lot of short notes and written updates to GitHub. I felt like it would be good to maintain a digest of these changes and thoughts in this journal, alongside my longer form writing. Therefore I did a bit of searching and found information about the atom feeds for “commit” changes (here: http://stackoverflow.com/questions/7353538/setting-up-an-github-commit-rss-feed). In order to display this feed, I needed an aggregator. I selected the CyberSyn plugin as it has been updated recently and offers excellent functionality (https://wordpress.org/plugins/cybersyn/). However, as the GitHub commit posts are a bit code-like and lacking correct grammar, I don’t want them on the front page of this journal but in their own category. So I set the CyberSyn plugin to set all feed posts as a new “development log” category and used the Ultimate Category Excluder (https://wordpress.org/plugins/ultimate-category-excluder/) plugin to omit that category from the front page posts feed. I’m pretty happy with that!
Lawson, B., & Sharp, R. (2012). Introducing HTML 5 second edition. Berkley, CA, USA: New Riders.