Per ardua ad astra

-Translates into ‘through adversity to the stars’. Personal interpretation: ‘a task may seem hard or impossible, but you will accomplish it – and won’t that feel sweet!’

This post describes work that was completed between April 3rd and the very early hours of April 5th – testing day. With all of the individual components of the web app produced and coded, these few days were spent putting everything together and adding the final touches, such as animations, to each of the components.

How the components came together (in short)

In the most basic terms, each component is its own HTML page that uses a shared CSS styleseet and a shared JavaScript script, called ‘core.css’ and ‘core-nav.js’ respectively. These files contain CSS properties and JS scripts that are required for the individual components, for example text size and font is consistent across the components, so is set in ‘core.css’. The clipping paths for the images were also standardised, so these are located in ‘core.css’. The same goes for the animations (more on this later). As its name suggests, ‘core-nav.js’ is responsible for key navigation, so this needs to be applied to each page.

There are also bespoke stylesheets and scripts for each component that contain CSS properties and scripts that are unique to the experience/component in question. For example, all of the JavaScript relating to the operation of the 360 degree experience is in a file called ‘360deg.js’ and only runs on the 360 degree experience page since it does not need to be loaded for the other areas of the web app. This helps improve performance and code management.

CSS animations were added by Ameer to make moving from one from HTML page to another a more seamless and ‘app-like’ experience as opposed to making it look like navigating a website. More on these later.

jQuery Mobile

Originally, Jamie was keen for us to look at jQuery Mobile and see how that could be used to code a web app. A prototype of the first few pages of our web app built using jQuery Mobile even exists.

The benefit of using jQuery Mobile is that it makes creating single-page web apps relatively straightforward and can animate slide up/down transitions between visible and hidden divs. The way it works is actually quite similar to the original Broads app prototype that I made in February, but with a lot less manual coding required on the JavaScript side. Each page is actually a div on one HTML document and depending on what you click or tap, one div is hidden and another shown.

The big disadvantage with jQuery Mobile however is that it is old. The latest stable release is from October 31st 2014 and latest alpha from January 2017 and it still only runs on jQuery 1.x. It is not compatible with jQuery 2.x or 3.x, meaning that some of the additional JavaScript required to run several of the experiences correctly won’t work because they use code that jQuery 1.x does not support. There are also potential security risks with using jQuery 1.x that make jQuery Mobile an unattractive option in 2019. Many versions of jQuery older than 3 are vulnerable to Cross-Site Scripting (XSS) attacks. These exploits were discovered in 2018, years after the latest stable release of jQuery Mobile was created and about a year after the latest alpha release. There are lots of threads on programming forums and even GitHub discussion groups asking if ‘jQuery Mobile is dead’ and many of these are from several years ago now.

I found the jQuery Mobile implementation to run slowly in a modern web browser (Chrome 73) and although it can add transitions in for you, it’s still not possible to swipe across the screen to hide and show divs, making it not an awful lot better than the solution we eventually took.

I also found the HTML code fairly lengthy and it was difficult to follow once you had more than a few screens coded in with it. I did try and use jQuery Mobile to make this, but in the end it was going to be a lot quicker and easier to create this web app like a normal website – especially since I effectively had only one complete day to make this.

Video demonstration of the jQuery Mobile implementation of the core pages below.

When it came out in 2010 the mobile design landscape was completely different to how it is today. There were many ‘feature phones’ and smartphones that ran proprietary operating systems, such as Samsung Bada, which all ran on Java and thus also had proprietary web browsers which meant that browsers and code for designing responsive websites could not be standardised. CSS media qureries didn’t really exist and wouldn’t become a part of CSS 3 until mid-2012 (and even in 2014, some designers were still relying on using percentages rather than pixels for measurements as a way to construct mobile designs, or simply loading ‘mobile stylesheets’ if a certain viewport width or height was not met), so at the time jQuery Mobile was probably a good solution to a fairly complex problem.

The Samsung Wave II came out in October 2010, not long before jQuery Mobile was released. It was a high-end phone that ran Samsung’s own Bada OS. The Wave line of phones and Bada is long dead.

But as we are finding more and more with CSS these days, eventually what you needed to use jQuery to do can now just be done in CSS. We’ve seen this already in this web app – the ‘scroll-behavior’ property in CSS negates the need for jQuery or JavScript smooth scrolling methods and CSS ScrollSnap negates the need for a jQuery or JavaScript solution for this. Media queries in CSS also make mobile web design possible without the need for jQuery or JavaScript.

The dated looking website featuring images of BlackBerry and Palm devices (as well as HTC Sense devices) shows that jQuery Mobile likely hasn’t been updted for a while.

Alternatives to jQuery Mobile

The final prototype was coded in a similar way to a traditional website, but when writing this post I did do some research on some jQuery Mobile alternatives. The frameworks below are all dedicated for creating mobile web apps.


It’s open source and runs on Vue, React and Angular which are all modern frameworks that are still supported, however you don’t need to know the ins-and-outs of how these work in order to use Framework7 – all the developer needs to know is HTML, JavaScript and CSS. This is known as a ‘library agnostic framework’. It includes animations, includes the native iOS and Android ‘look and feel’ and is extremely fast, apparently.

OnsenUI 2

The original version did require knowledge of Angular, which OnsenUI runs on, but OnsenUI 2 is also library agnostic. It includes UI components such as iOS UI elements and UI elements from Material Design, by Google.

Ionic Framework

Very powerful, but not library agnostic – the developer needs to have knowledge of Angular. If you’re already using Angular then this is a good solution. Very fast and smooth and has several UI components out of the box.

Adding CSS animations

Another thing that CSS can now do that you once had to use JavaScript or jQuery for is animations.

CSS animations were used extensively in my Nellie’s Nursery webiste prototype (my Year 1 final piece) and Ameer chose to use a mix of CSS animations and the ‘animate.css’ library to apply subtle animations to this web app prototype. CSS animations are generally very cross-browser compatible and have been around for a little while.

We chose Ameer to design and apply the animations with him being an interaction designer and interested in this kind of thing. Below are the animations for the web app prototype that Ameer produced.

‘Fade in’

@keyframes fadein {
    0% {
        opacity: 0;
        transform: translateX(100px);

    100% {
        opacity: 1;
        transform: translateX(0px);

This animation simply fades content into view, starting with an opacity of 0% and positioned 100 pixels off the screen. By the end of the animation, the opacity is 100% and the content is visible on the screen, having come in from the right.

‘Fade in down’

@keyframes fadeindown {
    0% {
        opacity: 0;
        transform: translateX(100px);

    100% {
        opacity: 1;
        transform: translateX(0px);

This animation is similar to the above, but moves content in from the top of the screen.

‘Fade in left’

@keyframes fadeinleft {
    0% {
        opacity: 0;
        transform: rotate(90deg);
        transform: translateX(-100px);

    100% {
        opacity: 1;
        transform: translateX(0px);
        transform: rotate(90deg);

As above, but this time the contents fades in and flies in from the left of the screen. It also rotates as well – this is because this animation is specifically for the right (or ‘forwards’) arrow which needs to be rotated by 90 degrees to make the correct shape.

This animation is only available on the index/welcome page and on the theme landing pages because these are the only pages to feature a left arrow button.

The animation in action.

‘Fade in right’

@keyframes fadeinright {
    0% {
        opacity: 0;
        transform: rotate(90deg);
        transform: translateX(-100px);

    100% {
        opacity: 1;
        transform: translateX(0px);
        transform: rotate(270deg);

As above, but for the left arrow buttons, so the rotation is set to 270 degrees.

Left arrow animation, shown in the finder app.

‘Scale in’

@keyframes scaleanim {
    0% {
        transform: scale(0);

    100% {
        transform: scale(1);

This transition ‘zooms’ an object into view, starting from 0% scale and eventually being displayed at 100% scale throughout the duration of the animation.

The scale animation as seen in the finder app. See the hero images zooming into view.

Applying the animations to elements

Animations are defined in the shared stylesheet ‘core.css’ and are applied to elements in the stylesheets respective to the component, for example animations for components on the map are applied in ‘map.css’ and animations for the finder in ‘finder.css’ and so on. Below is an example from the finder, where the animation ‘scaleanim’ is applied to the hero image on the finder information pages:

.hero {
    animation: scaleanim 1s ease-out; /*located in core.css*/

This applies that information to the class ‘hero’. The animation is 1 second one and has an ease-out transition. The comment notes that the animation is defined in ‘core.css’ just in case the animation itself ever needs to be changed.

Some animations are ‘global’, meaning that they are applied to elements in ‘core.css’ and thus run in every component. A good example of this is animating the body copy appearing on all pages, done by applying the animation ‘fadein’ on the element ‘p’ in ‘core.css’.

p {
    animation-fill-mode: backwards;
    animation-delay: 1s;
    animation: fadein 1s ease-out;

This animation is delayed by 1 second to ensure that the other items have loaded and appeared before the body copy animates into view to create a more polished appearance.

Animations from the animate.css library

Ameer also utilised the animate.css library to animate several of the other elements in the web app. The library is available on Cloudshare and the URL to it can be placed as a stylesheet URL at the top of any HTML document to begin utilising its features.

Animations from animate.css work a little differently. Animate.css is a large CSS stylesheet with pre-written CSS animations (defined as classes) that you can add to your elements in HTML by appending the classes from animate.css onto your HTML classes. Example below, showing an animation/class called ‘animated fadeInRight’ being appended to the ‘header’ class:

<div class='header animated fadeInRight delay-1s' id="history-button">
    <div class='headerContent'>

‘animated fadeInRight’ is a class in that animate.css stylesheet and ‘delay-1s’ is also a class in that stylesheet, which delays the animation by a second, likely by using the ‘animation-delay’ CSS property.

The benefit of using that animate.css library is that you don’t have to spend time writing your own CSS animations!

These animations are used for the theme selector page, all pages with buttons in the finder app and several other elements on other pages.

The animations for the buttons on the theme selection page are done with animate.css.


The animations for the buttons on the finder app are also done with animation.css.

Reflections on the animations

Ameer did an excellent job with these. The animations really help to make the app a pleasant experience to use and also help to hide the ‘transition’ between the different pages in the app. It helps that the page background on each page is the same colour which makes the animations look sleeker. The nature of CSS animations makes them very easy to apply to elements and Ameer also fully explained how to implement the animations from the animate.css library too. This was a great example of teamwork in action.

The final 4 hours – putting it all together

Starting at around 9pm on the evening of April 4th, I finally began putting everything together. I knew that jQuery Mobile was going to take too long to look into at this point in time (I had attempted to start putting this together with jQuery Mobile the previous night), so I began to code this like a normal website.

With the work from my peers on the NUA BSc GitHub, I downloaded it all and spent the next 4 hours putting everything together.

Directory structure

The directory structure is fairly simple, with each component being it’s own HTML file, generally stored in the root directory and images being stored in the directory ‘img’, with the exception of the images that appear on the grid experience which are in the directory ‘grid-images’. Icons for the map appear in the directory ‘icons’. CSS is stored in the ‘css’ directory and JavaScript is stored in the ‘js’ directory, as per most website directories. These folders are all stored in the root directory.

The nature finder’s opening page is ‘finder.html’, stored in the root. The individual HTML files for each stage of the finder app (1-5) are stored in their respective individual folders in the root directory of the website.

Font files are stored in the ‘font’ directory.

The directory structure as shown in the Visual Studio Solution Manager.

Integration – ‘core-nav.js’

The file ‘core-nav.js’ is a 63 line JavaScript file that is applied to all HTML files in the web app. It controls key navigational aspects of the app that links the HTML pages (apart from those in the nature finder) together.

All of the ‘leftArrow’ CSS divs (i.e. the left arrow buttons) return to the previous page on the browser using the code in core-nav.js below:

function goBack() {

$('.leftArrow').click(function () {

Every left arrow is a ‘back’ button, so it made sense to link the code to the class rather than assign an ID to each one and link each ID.

All of the various logo classes go back to the theme selection page, this essentially makes the logo on every page act as a home button.

 $('.logo, .logoWhite, .logoRed').click(function () {
    location.href = "../theme.html";

The map is an HTML page that is available on every page by tapping on the map icon that is at the bottom of each page. The map button on every page is assigned the ID ‘open-map’ – when this is clicked, the map opens. The ID of the close button at the top of the map page is called ‘close-map’ and this closes the map by running the ‘goBack’ function when the button is tapped.

$('#open-map').click(function () {
    location.href = '../map.html';

$('#close-map').click(function () {

This negates the need to code the map into every HTML page and hide and show the map using CSS or jQuery hide and show commands – now it’s just a page that is opened and closed. All that needs to be coded into each page now is the map button that sits at the bottom of the page.

Demonstration of the map opening and closing on the finder page.

Putting the map into the completed web app wasn’t quite as straightforward as copying the HTML, CSS and JavaScript from my prototype into the final project. When I was writing the map prototype, I forgot to include the following CSS in the map’s stylesheet:

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;

This CSS is commonly used by web developers to remove the default margins and padding from webpages. When I moved the map into the completed prototype, this code was present in ‘core.css’ which the map HTML file was reading and applying it, removing the default margins and padding and thus also altering all of the original measurements and some of the element alignments in the map. This is why the position of some elements in the GIF above looks different to the map demonstrations in the previous post – most notably the alignment of the items in the drop-down menu for the locations is not quite centred. This menu was fixed very quickly with a ‘sticking patch’ solution, shown below:

.location, .location-picker {
    /*text-align: center;*/
    padding-left: 10vw; /*TEMPORARY FIX*/

Using the text-align property was causing problems with the text appearing outside of the div, because somehow the div class was now extended across the top of the map, so instead setting a left padding was used as a temporary solution. The trouble is that this ‘almost centres’ the text on some devices, but not quite all. An emulation of an iPhone 6/7/8-sized device is shown in all of the GIFs in these posts.

The other trouble was that the close map button is positioned by using a margin-top position which is absolute, so on some larger phones it doesn’t display in the correct place (rather a few pixels above the map container). I knew that we’d be testing this on a Samsung Galaxy S8, so I put in a media query to change the margin-top property depending on the screen viewport height.

@media only screen and (min-height: 700px) { /*patch for S8*/
    #close-map {
        margin-top: 8vh;

The ‘core-nav.js’ file also controls the navigation from the theme selection page and then the navigation from each of the theme landing pages to the respective experiences – that’s the finder for the nature landing page, the grid for the heritage landing page and the 360 degree experience for the landscape landing page.

The code for the buttons on the theme selection page is below:

$('#nature-button').click(function () {
    location.href = '../nature.html';

$('#history-button').click(function () {
    location.href = '../heritage.html';

$('#landscape-button').click(function () {
    location.href = '../landscape.html';

The code for the right arrow/forward buttons from the landing pages to the respective experiences is below:

$('#nature-landing-right').click(function () {
    location.href = "../finder.html";

$('#history-landing-right').click(function () {
    location.href = "../grid.html";

$('#landscape-landing-right').click(function () {
    location.href = "../360deg.html";

This code that appears at the bottom of the file is my failed attempt at making the left button on the grid go back to the previous screen. This was discussed in the previous post, but the code was never removed from the bottom of the core-nav.js file.

The JavaScript for the individual components

For the most part, the JavaScript has always been unique for each component, meaning that putting the JavaScript into the web app was just a case of appropriately naming the files and changing the links in the HTML files. The only JavaScript that needed to be run on each page is the core-nav file which contains the navigation, explained above. The JavaScript would probably not execute correctly if it was all in one file – and not all bits of that file would be applicable to all pages – so they remain as individual files.


This was a lot harder, because there was/is a lot of shared code in the CSS that needed to be put into one ‘shared’ CSS file, accessible to all files, then individual/unique elements for the various components would need to be in separate stylesheets. Elements in unique stylesheets would need to have unique names or the !important CSS rule would need to be used if elements shared the same name, as to not overwrite properties.

This was the bit that took the longest to get right. In the final web app prototype there are some styles between the various stylesheets that are duplicated which I didn’t notice in the very short time space I had to make this. On the whole though, the stylesheets are unique and the ‘core.css’ file was written to contain the universal styles such as:

  • Font definitions
  • Styling for type, e.g. definitions for h1, h2 and p tags
  • Clipping paths for the hero images (so they are standardised)
  • Background colours for the pages
  • Logo classes
  • Left and right arrow button styles

These are needed across all of the pages.

That leaves the CSS files for the individual components generally being the same as those for the prototypes, minus any links to the above.

The final commits

With the code as good as it was going to get, the final commit was made on April 5th at 00:37am. As you can see from the screenshot of GitKraken below, there was one final patch raced out in the morning after the final commit of the evening. This patch fixed an issue with the aquatic species page not linking to the correct page.

The commit history for the web app.

This was it. The app prototype was made, the experiences were coded and good enough for a prototype. In a few hours, all of the work from the group had been ‘married together’ and working perfectly.


-Me, when I tested the app prototype on the Samsung Galaxy S7 I had borrowed from university and it worked!

The group was happy to hear that the web app was completed.

The group hears that the app is completed.

View the completed prototype

View in your browser here.

View the source code on my BitBucket here.


First off, the coding was going to be something that the graphics students were likely going to learn a bit about, but realistically not do, and the creation of the identity and the signage something that we’d [UX designers] learn about, but not do. This collaboration project aimed to take graphic design and marry it with UX design and coding to produce what we have produced – a functioning web app, built on user research and good graphic design principles. The web app could then be tested with users in an ethnographic setting to find any pitfalls.

The graphic communication students and the UX and interaction design students worked fantastically together. We’ve all gotten on really well and become good friends – as well as produce an app that we are proud of. The designs from the graphics students has translated well into code and I think they’ve all been really interested to see this turn from an idea, to prototypes on Adobe XD to code running in a web browser.

Working with the graphics students

I feel that my own performance has been good. I’ve worked in the team and taken on ideas from people and also helped people where they have needed it. I’ve also learned a lot from the graphics students about the design side of things – which is what this project intended to do. I know that my strengths do not lie in graphic design, or UI design and the professionals that I’ve worked with in industry can back this up. Working with the graphics students has enabled me to see how they work, the choices they make, the sources of their inspiration and the outcomes that they produce. I hope that they’ve found observing how we as UX designers and developers work. At a networking event on April 11th, a few weeks after this was made, I introduced Corrina to Tom Haczewski from The User Story (whom I worked with for a bit in late 2018) and she said to him how she had found it interesting to see how what we do is different to her practice, but now she understands why we do what we do.

Working in this team has been excellent and I feel that we have all learned a lot from each other.

Working in a team – ‘follower’ vs ‘leader’ and regrets about workload

Having an interest in coding, I took a lot of this work on as a personal challenge. I wanted to try and make a grid framework, I wanted to try and make the map and I wanted to be the one to string it all together. Whilst I think it’s good that I was ambitious, as mentioned a bit in the previous post, it doesn’t always show fantastic teamwork as it can potentially deny others the opportunity to do these things. I have always been somebody who is more of a ‘leader’ than a ‘follower’ and I’ve always been a bit of a ‘control freak’. I’ve always liked having control in groups to ensure that standards are met and work is done. This probably makes me quite difficult to work with.

I pushed myself to become the Head of Storehouse because I really wanted it and the magazine needs somebody to coordinate it all. In the case of this project, I was very aware that this was not meant to be some kind of Apprentice-esque style task where there is one ‘project manager’ and the others follow his or her’s commands, so I tried not take control and instead just let the team do what it needed to do to get the job done. However, people seemed to naturally turn to me and ask me what to do next when they had completed their tasks, almost as if I were some kind of project manager. Perhaps it’s just a vibe that I give off. I was happy to suggest what to do next and suggest the next steps, but it was always at the back of my mind that I needed to show for this unit that I could work in a team and not necessarily be the one making decisions.

The team working hard on April 4th, one day before testing.

On the other hand, part of working in a team is recognising people’s strengths and weaknesses, as well as your own, and playing to them. Perhaps this is more the personality of a leader, but I recognised that Chloe, Corrina and Zach were great at designing the identity and the visuals, so I trusted their judgement with that. I recognised that Namii was great at information architecture and was also very good at arguing strong reasons for and against design decisions based on user research, so I trusted her judgement with those things and let her be the one to challenge the designs produced by the graphics students. I saw that Chloe, Namii and Ameer in particular enjoyed prototyping and using software like XD to do that, so I felt that they should do those tasks. Ameer as an individual has a strong interest in animations, the way that designs translate into code and appear on-screen and also dislikes JavaScript and the more technical back-end web development – so it made sense for him to focus on the front-end coding and leave the back-end to somebody else. I saw that my skills filled the gaps and so coding this seemed like the perfect role for me.

Sometimes I think by going in there and coding the map and putting everything together I perhaps denied Ameer the opportunity to learn some new JavaScript skills that maybe he had wanted to learn by volunteering to do the map. He didn’t seem too disappointed about not having to put the whole thing together in a short space of time, but I think he was surprised that he didn’t get to code the map – especially with his Year 1 final project being all about mapping. I enjoyed coding the map and felt that my solution involving the use of arrays was a good one, but part of me feels that maybe he should have done that task.

Teaching Namii how to code some of the CSS and JavaScript was a clever move, I thought. She learned how to code and enjoyed the challenge and the sense of achievement when things worked. She’d often run into a problem, tell me what she thought the problem was, then go and fix it herself using what I had taught her. The perfect student, really! Her coding the core pages and the vast majority of the finder app saved me an awful lot of time and legwork, so it was a two-way mutually-beneficial transaction.

Ameer and Namii coding together (March 28th 2019).

Am I leader?

Yes, I think so. But what kind of a leader am I? There are several different styles according to the book ‘The designer’s field guide to collaboration’ by Caryn Brause (Brause, 2016, p. 116).

  • Relationship masters
    • Good at: building communities, display regard for the views of others, building consensuses and good at keeping the team together.
    • Bad at: not wanting to voice unpopular opinions, taking risks, putting work before relationships.
  • Spontaneous motivators
    • Good at: having visions, motivating people, passionately voicing ideas, delivering energetic dialogues.
    • Bad at: dealing with objectivity and often becoming too emotionally attached to ideas, thus creating emotionally-chard environments.
  • Analysts
    • Good at: translating feelings and experiences into ideas, analysing situations and getting details and seek information and opinions.
    • Bad at: they tend to only focus on one or two ideas and can be slow to come to a conclusion.
  • Drivers
    • Good at: giving information and opinions, making decisions quickly, keeping the vision together and prepared to stand up to issues.
    • Bad at: accepting that others may be indecisive or take longer to make decisions, often makes decisions without input from others and makes mistakes when moving too quickly.

I honestly see a bit of ‘me’ in each of these, but the one that I resonate most with is the ‘driver’ persona. When running Storehouse magazine and even this project, which I wasn’t even officially running, I always got my point across and tried to keep the team together and interested in the project at hand.

How this project can help me find my career path

It’s interesting though, because I’ve written here about how I like being a leader and assigning tasks to people, so perhaps an ideal career choice for me would be working freelance and directing myself – but my freelancing experience hasn’t been amazing (as outlined in this post) and so it’s not an option that I want to pursue as a new graduate, at least.

Still, even if that doesn’t make sense then at least this project has confirmed everything that Tom Haczewski said to me at the end of my work placement at The User Story in January 2019. He said that information architecture, research and coding were my skills. Prior to the graphics students getting involved, I felt that I was doing a great job at the ethnographic research and was able to drive a lot of meaning from data and spoken word which went into producing this prototype. Tom said that the visual design wasn’t my strongest point and working on this project, that seems to be the bit I’ve avoided doing. Not because of what Tom’s said, but just naturally. I know I’m better at other things.

Even teaching has come back onto my radar. I enjoyed teaching Namii the CSS and JavaScript and seeing her improve – she’s really proud of the code she’s written! She’s mentioned several times that she thought I explained it well. This post and the last one especially feel more like a ‘step-by-step guide’ than a production diary or reflective journal. I enjoyed recording the two videos in the previous post where I explain my methods and show them working. It was good teaching Chloe too and I was happy that she understood the differences between classes and IDs in CSS an awful lot quicker than I did! Teaching school children would be very different to teaching Namii and Chloe and recording a few tutorial videos, but I’ve always been keen to share knowledge and have been very interested in the education landscape for the past 4-5 years. Read my full thoughts on education and teaching here and here.

Code evaluation

Firstly, it was great fun researching all of these new bits of CSS and JavaScript. There’s nothing I love more than a challenge and having to think outside of the box. When people were explaining problems to me, or showing me designs, I was writing the code in my head. The past month or so has been so much fun with the coding – everything from learning about MarziPano to CSS ScrollSnap and coming up with what I think are good solutions to problems. This is why we are coders – we problem solve and we relish in it – even if weird incompatibilities between libraries and plugins irritate us at times!

The code that I have written is as good and as elegant as I could make it at the time. In hindsight, there are things that I could have done better such as perhaps naming elements more consistently and also not thinking ‘too radically’. Sometimes I feel that I try to create very elaborate and technical ways to solve fairly small problems – a good example being getting the left button on the grid to go back to the previous page. My initial ‘elaborate thinking’ resulted in trying to write a script that changed the ID of an element when a certain variable was true – and it didn’t work. I didn’t have a lot of time and at the end of the day there were more important things to be dealing with, so I left it and this functionality was not present. Upon writing the previous post and explaining my methods, I saw that actually a much clearer and more elegant and simple solution was in plain sight – it’s just that I had my ‘eyes wide shut’ when I was busy trying to come up with that elaborate solution. I guess I become all proud of complex solutions because I think ‘wow – I thought of this!’ but really, sometimes simple really is better.

The bits of code from this project that I am proudest of are:

  • The scroll listener on the grid that listens for scrolls and calculates the row that the user is on based on their scrolling. Even though in practice this is a terrible idea (potentially), it was an inspired idea and felt it was a very logical solution.
  • The map and how it uses arrays to load different maps and change the name of the location. A simple but effective idea.

Some things could have been taken further, for example the nature picker could have possibly found the wildlife by searching through an array (a little like the map), but the scope of the project did not call for anything as complex as this.

On the whole, the code is good and I am pleased with it! Especially given the short time frame that I had to put it together. I learned new things too, which makes this even better!

Next time I’d be interested in experimenting with one of the more modern HTML 5 web app frameworks mentioned earlier. Framework7 and OnsenUI 2 seem especially interesting, especially since they utilise things like React and Angular, yet to use them you don’t need to know those tools. Perhaps in a personal project I could utilise one of them. A dedicated web app framework would make things like animations, transitions between pages, navigation and accessing phone hardware such as the camera and gyroscope easier.

From site visits to ideas on post-it notes, to designs in XD to a fully-coded web app prototype running on a phone. Perfect code or otherwise, we made it!

Course satisfaction

Honestly, since January and especially for the past month, my satisfaction with the course has never been higher. This has been an excellent project that I have thoroughly enjoyed for a lot of the reasons mentioned earlier. I’ve gotten the chance to play with so much cool tech and code and do some great research, make a good prototype and make great friends and eat pizza along the way. What could be better?


Brause, Caryn (2016) The Designer’s Field Guide to Collaboration. Routledge

GitHub. (2018). Can we all admit this project is dead? · Issue #8612 · jquery/jquery-mobile. [online] Available at: [Accessed 15 Apr. 2019]. (n.d.). Changelogs | jQuery Mobile. [online] Available at: [Accessed 15 Apr. 2019]. (n.d.). CSS Media Queries. [online] Available at: [Accessed 15 Apr. 2019]. (n.d.). CSS scroll-behavior property. [online] Available at: [Accessed 15 Apr. 2019]. (2014). Is jQuery Mobile dead?. [online] Available at: [Accessed 15 Apr. 2019].

Quora. (2017). Is jQuery Mobile dead? Any good replacement?. [online] Available at: [Accessed 15 Apr. 2019]. (n.d.). Jquery : Security vulnerabilities. [online] Available at: [Accessed 15 Apr. 2019].

Patwardhan, S. (2018). Moving on 😢 – Life after jQuery Mobile. [online] The UI Dev. Available at: [Accessed 15 Apr. 2019]. (2012). Media Queries. [online] Available at: [Accessed 15 Apr. 2019].

What’s next?

Go and test this web app prototype with the WI in Oulton Broad!