Following my previous reflective journal, here is my reflective journal and production diary for 5-9th March 2018!

Week reflections

Wow! What a busy week it has been! I’ve been working like crazy on both the Nellie’s Nursery website and the Storehouse university magazine website. I’ve been developing the two side-by-side, so my week has been pretty much 100% coding with little time for anything else! Dedicating so much time to coding and developing these two sites together has meant that according to my schedule that I created last week, as of Sunday 11th March I am roughly where I need to be or possible even a little ahead of schedule.

This week I have successfully:

• Duplicated Mobile Prototype 1 to make the basis of Elebase 3.
• Created the icons for the new menu system, which are the ‘menu’, ‘contact’ and ‘home’ buttons that my extensive research concluded users knew instantly.
• Creating the new menu system using a jQuery SlideToggle to hide and show a div with buttons in it when the menu button is pressed.
• Refining the menu and making sure that all of the buttons are visible on various smartphones.
• Perform some provisional testing to make sure it is working as expected.
• Adjusted the media queries to reflect the changes that have been made to the website.
• Ensured that all images that are currently in the website are responsive.

Monday 5th March

Today I started making the menu system for the Storehouse website which is actually very similar to that of Nellie’s Nursery. Below is an animation of how I envisaged the menu system for the Nellie’s Nursery Elebase 3 prototype being.

The Storehouse Online design team decided that they wanted to have a similar bottom-placed fixed navigation on the Storehouse site, a little like what had been proposed for Elebase 3. The difference is that the Storehouse one would be a black rectangular bar rather than a curved menu and would only feature the hamburger button which the user would tap and reveal links to the home page and the other articles. I felt that I would make sense to code the navigation for Storehouse and then adapt it to suit Nellie’s Nursery.

Below is an animation showing how the completed looks in the latest Storehouse prototype (version 5.5.5 as of Sunday 11th March).

The menu button was made in Photoshop and was simple made by drawing a line shape, increasing the thickness and then duplicating the layer twice and placing the lines on top of each other. This seemed the easiest way to make a hamburger menu icon.

The actual menu itself is a div class called ‘.hamburger’ on every article page and the code looks like this:

The code is placed at the bottom of each article page outside of any containers or any other divs. It is always the final div to be defined in the HTML. The <li> tag is a list element in HTML and the <p class=”menuItem”> tag puts the text in a text formatting class called ‘menuItem’ that we defined in CSS. These are all just to set the styling of the menu system to fit the Storehouse branding which is very strict and won’t apply to Nellie’s Nursery at all.

Navigation is handled through jQuery. I find that jQuery navigation is a great thing because you can simply link the JavaScript file to the HTML and the navigation is relevant to any pages that have that JavaScript file linked. I can simply update one JavaScript file and any pages that the file is linked to are also updated. For websites with lots of pages I prefer using jQuery for navigation than define navigation in HTML for this reason.

The jQuery navigation code is a little like this:

// Navigation

$(document).ready(function () {

    //Logo button for home, thanks and error pages ONLY
    var logoHomeVibrate = $('#LogoHome').vibrate("long"); //Vibrate is only available on Android devices
    $('#LogoHome').click(function (logoVibrate) {
        location.href = 'index.html';
    });

	//Logo button for article pages ONLY
	var logoVibrate = $('#Logo').vibrate("long"); //Vibrate is only available on Android devices
	$('#Logo').click(function (logoVibrate) {
		location.href = '../../index.html';
	});

	//Article links for hamburger menu ONLY
	$('#amy-harman').click(function (e) {
        location.href = 'amy-harman-issue16.html';
    })

    $('#bethany-graham').click(function (e) {
        location.href = 'bethany-graham-issue16.html';
    })

    $('#carter-osullivan').click(function (e) {
        location.href = 'carter-osullivan-issue16.html';
    })

    $('#cat-cousland').click(function (e) {
        location.href = 'cat-cousland-issue16.html';
    })

});

And so on – there is more but this extract of code should give you the idea. By making sure that each button or text link has an ID, you can tell jQuery to navigate to a page when this button or text is clicked or tapped on using a click event.

I should also mention the ‘vibrate’ library. There is a jQuery library called ‘vibrate’ that you can download which on certain browsers (namely Chrome and Firefox, both on Android) can activate the phone’s vibration motor and make the phone buzz or vibrate when a button is pressed. The vibrate.min.js file needs to be linked to the HTML page, then in JavaScript a variable needs to be defined as the vibration (‘fast’, ‘long’ and a custom time in milliseconds can be defined) and this variable can then be passed into the click function as a parameter replacing the (e) placeholder parameter. This will make the button vibrate as you tap it. Unfortunately this feature is only available on Android devices, apparently it was once available on iOS devices in Safari but has since been deprecated. I feel that the vibrate will make the button feel more like a ‘button’ bearing in mind that they are tapping a touchscreen and some users feel that buttons on touch devices lack that tactile feel. It’s also good to have unique features on your website to make the experience of using it more memorable. Very few mobile sites have tactile buttons on their mobile sites, so Storehouse and Nellie’s Nursery will be unique in this field.

In the main stylesheet for the Storehouse article pages, the .hamburger class properties are defined.

.hamburger {
    position: fixed;
    height: 100%;
    width: 100%;
    text-align: left;
    bottom: 0;
    background-color: white;
    visibility: hidden;
    z-index: 20;
    padding: 5% 5% 5% 5%;
}

By having the div fixed and setting the width and height to 100%, it will always be able to fill 100% of the page space. By default, the hamburger menu is of course hidden by default as it is only visible on the mobile site. The Storehouse hamburger menu features a white background and black text (black text not defined as it is the default). I chose to use ‘bottom: 0;’ because by specifying that the hamburger menu slides out from the bottom of the website when the hamburger button is pressed. If I used ‘top: 0;’ it would slide out from the top or if I used ‘left: 0;’ it would slide out from the left. The jQuery SlideToggle function uses this CSS property to determine where to animate from.

There is a small bug where sometimes the CSS is loaded a few seconds after the page load and so sometimes the hamburger menu is visible for a split second and then disappears once the styling is applied. This bug can be circumvented by placing the following jQuery script in the head area of any HTML page which the hamburger menu needs to be active on:

$(document).ready(function () {
    $(".hamburger").hide();
});

This just tells the .hamburger class to be invisible as soon as the page loads and that ensures that the menu is not visible at all until a media query detects that the screen width has fallen below a certain value – more on that later. Of course, since the script is running directly inside a HTML document it would be enclosed in script tags, but to prevent WordPress from trying to run the script on this page I have removed these tags from my code extracts.

The bottom menu bar is also defined as a class on each HTML page it needs to be active on and its style properties are defining in the main stylesheet. This is of course the black bar that the menu icon sits in.

The HTML for the .bottommenu class looks like this:

It is always defined above the .hamburger class and unlike the hamburger class, it is always in the container so that it can be positioned more easily. There is only one thing in the class and that’s the image of the menu icon which has a height of 50px on the Storehouse website to keep it reasonably-sized and reduce wasted screen estate. The taller this image is, the taller the menu bar that it sits in becomes and thus the more screen estate is lost to the menu bar.

The CSS on the main stylesheet is as follows:

.bottommenu { /*visible only on mobile*/
    visibility: hidden;
    background-color: black;
    position: fixed;
    padding-top: 0.5%;
    width: 100%;
    bottom: 0;
    text-align: center;
    z-index: 200;
}

The code for this is virtually the same code as used for the fixed bottom menu in Nellie’s Nursery Mobile Prototype 1, written over a month ago at the time of writing. Like the hamburger, it is hidden by default as this class is only activated on mobile devices. By making the position fixed and aligning the class to the bottom of the page using the ‘bottom: 0;’ line, the menu is always static at the bottom of the page. Using ‘text-align: center’ means that anything in the div is centred, so the menu icon is placed perfectly in the centre of the div. There are other ways of going about this, but this is a good way as it’s quick and easy to do and it just so happens that the ‘text-align’ property can also be used to centre align other elements.

The jQuery code to activate the hamburger menu is shown below. This is stored in its own JavaScript file called ‘hamburger.js’.

There is a lot of debate about whether having one long JavaScript or CSS file is better than having lots of smaller ones. I’ve found that generally having large JavaScript files isn’t a great idea and sometimes they don’t even work as well as smaller ones especially when they are being referenced by multiple pages and if some of the things in the JavaScript file are not relevant to the page. By breaking down the files you can only link the relevant files to the relevant HTML pages which improves compatibility and the chances of the code executing correctly. CSS files, generally the fewer the better in my opinion as it’s easier to repeat code by having multiple CSS files and I’ve found that CSS as a language is generally more ‘resilient’ meaning that if things are referenced in the CSS file that don’t exist in the HTML page it is linked to, instead of the code not executing altogether, it will simply ignore anything that it cannot find on the HTML page. This means that it is easier to write long CSS files than JavaScript files.

$(document).ready(function () {

    $(".hamburger").hide();
    var menuMobileVibrate = $('#menu-mobile').vibrate("long"); 
    $("#menu-mobile").click(function (menuMobileVibrate) {
        $(".hamburger").slideToggle("fast", function () {
        });
    });
});

This jQuery code to activate the hamburger mode is practically the same code that is used to activate the hamburger menu in Nellie’s Nursery Mobile Prototype 2, with the exception that now the animation has been changed to ‘fast’ to make the menu appear quickly (some testers mentioned after doing testing on February 15th that the hamburger menu opened too slowly) and vibration has been added to the hamburger button itself.

Activating the hamburger menu and the bottom menu is done using media query, just like in the previous generation Nellie’s Nursery prototypes described in the reflective journal entries for Friday 9th and Saturday 10th February 2018. On the Storehouse website, when the screen width is 1000 pixels or less, both the bottom menu and hamburger are activated.

@media only screen and (min-width: 600px) and (max-width: 1000px) {

    .bottommenu {
        visibility: visible;
        text-align: center;
        z-index: 40000;
    }

    .hamburger {
        visibility: visible;
        z-index: 30000;
    }

}

The Storehouse website features several media query breakpoints, 600-1000px wide is just one of them. There is also a lot more code in this breakpoint than shown here, I’ve just removed the irrelevant code for the sake of this post. In fact, when the Storebase framework code was rewritten recently its media queries were based on that of the 5-point media query code that I wrote for the Nellie’s Nursery prototypes because they were so smooth and fluid. Storebase articles now run on a 4-point media query code.

To make the classes visible the visibility is set to visible, however the hamburger is still not visible when the user visits the page (even if the screen width is 1000 pixels or lower) because that little bit of jQuery code on the HTML page that hides the hamburger menu is still being activated. The hamburger only becomes visible once the menu button is pressed, but because the CSS properties of the hamburger menu now enables it to be visible, it can be seen when the button to show it is pressed.

By setting the z-index of the bottommenu class to 40,000 and the z-index of the hamburger to 30,000, the bottom menu is always visible even when the hamburger is open and covering the rest of the screen. This is critical as the user needs to be able to close the menu again by clicking on the button again.

Promoting my course

Recently I became an Outreach Student Ambassador for NUA, meaning that I get paid to help promote the university and its courses at various events all across the country. I’ve always loved promotion, promoting products and organisations (when I did work for Microsoft Education UK I did a similar thing and frequently spoke about Microsoft hardware and software at events in London and America, see my Friday 2nd March reflective journal entry for a little insight). Tonight my university were running ‘campaign calls’ which are calls run by students to prospective students who have an interview at the university but have not made their offer firm on UCAS yet. The idea is to talk to these students and give them an opportunity to ask any questions they might have about the university, the course, Norwich or anything university-related that they might want to talk about to help them decide if NUA is the university for them. I did the calls for all three of the BSc courses (User Experience Design, Interaction Design and Games Development) and rang up around 20 students in total over the course of two hours. Some students didn’t have anything that they wanted to discuss which was fine, but others I had fairly lengthy conversations with about what the university can offer them, how the courses work, what they can expect and even some advice about how to ‘survive A levels’!

I found it was an enjoyable experience and I felt very happy to have helped promote my course. I even got several of the students I was on the phone to to accept their UCAS offers for NUA there and then! I hope I made the others reconsider their offers for NUA and helped encourage them to come to NUA!

 

Tuesday 6th March

With the menu system for Storehouse made, it was time to implement it into the next Nellie’s Nursery prototype which will be tested on Friday 16th March.

The first step was to simply copy the Nellie’s Nursery Prototype 1 folder and then start modifying the code from here. Asides from the addition of the new menu system, the next prototype will be very similar to Prototype 1. I used the same menu icon as I had used for Storehouse and made new icons for the contact and home pages in Photoshop and saved these as PNG images. I then put the following HTML code at the bottom of each page in the website.

You’ll note that the code is very similar to that of the Storehouse site. There are obviously two more buttons in the fixed menu for Nellie’s Nursery and far fewer items n the hamburger menu, since the hamburger menu on the Nellie’s Nursery site only needs to include links to the home, day-to-day, groups, meet the staff, parents’ and contact pages.

Navigation between the pages is done using a very similar jQuery script as shown above for Storehouse and the Tuesday 13th February reflective journal entry.

One noticeable difference between Prototypes 1 and 2 and Elebase 3 are button classes. In Mobile Prototype 1, the buttons at the bottom of the page used the same classes as the menu buttons on the desktop version of the site, meaning that they were green by default and went orange when you hovered over them. They also went orange when the user was on the page that the button referred to.

In Elebase 3, I didn’t want the menu buttons in mobile view to be in coloured circles, so I instead I wrote a new CSS class called ‘menu-button’ and then as you can see the screenshot of the HTML code above, put my menu buttons in this class.

.menu-button {
    background-color: transparent;
    color: white;
    padding: 15px 32px;
    text-align: center;
    display: inline-block;
    font-size: 16px;
    margin: 4px 2px;
    cursor: pointer;
    border-radius: 160px;
    border: none;
    outline: none;
}

The big difference is that the background colour is now transparent and by setting the border and outline to ‘none’, web browsers (notably Google Chrome), won’t put an annoying blue box around the button to highlight the fact it has either been clicked or that it is a button.

The buttons in the hamburger menu itself use a very similar button class to that of previous prototypes:

.button {
    background-color: #aed2a7;
    border: none;
    color: white;
    padding: 15px 32px;
    text-align: center;
    display: inline-block;
    font-size: 16px;
    margin: 4px 2px;
    cursor: pointer;
    border-radius: 25px;
    border: none;
    outline: none;
}

There are a lot of shared attributes between the ‘menu-button’ and ‘button’ classes, it might have been more efficient for me to write ‘menu-button’ as a subclass of ‘button’, but at the time of writing the code I didn’t think to do this. This would reduce code repetition and thus make the code more efficient, as well as demonstrating a higher level of coding ability.

The CSS code for the hamburger class itself is very similar to that used on the Storehouse site, though perhaps a little more concise:

.hamburger { /*Visible only on mobile devices and low screen resolutions*/
    position: fixed;
    height: 50%;
    width: 100%;
    text-align: left;
    bottom: 0;
    background-color: white;
    z-index: 1;
    visibility: hidden;
}

The difference is that on the Nellie’s Nursery website there aren’t really enough items in the hamburger menu to warrant having the menu occupy all of the available screen space, so the hamburger only occupies 50% of the screen height. This still results in the buttons being plenty large enough to tap with one thumb (which having the buttons occupy 100% of the hamburger width helps with too) – see the screenshot of the buttons above.

The biggest difference between the menu systems on Storehouse and Elebase 3 is that on the Elebase 3 prototype the container for the menu buttons is a ellipse-shaped and doesn’t occupy all of the page width, whereas the Storehouse website uses a full-width rectangular container to house the menu button. I chose the design I did for Nellie’s Nursery because it felt more playful and in my opinion looks nicer. I don’t really feel the need to have a full-width menu bar when there’s only three items in the menu bar. The Storehouse team decided that they wanted the full-width menu bar so I had to respect their decision, but as I am designing the website for Nellie’s Nursery I get to call the shots at the moment (it might be changed if Phase 2 Testing on the 16th tells me that users did not like it though).

To accomplish the ellipse-shaped menu bar, the following CSS code is used for the bottommenu class in Elebase 3.

.bottommenu { /*Visible only on mobile devices and low screen resolutions*/
    visibility: hidden; /*Visible only on media query on mobile devices*/
    text-align: center;
    position: fixed;
    margin-left: auto;
    margin-right: auto;
    left: 0;
    right: 0;
    width: 60%;
    background-color: #aed2a7;
    z-index: 1001;
    bottom: 0;
    border-top-right-radius: 500px;
    border-top-left-radius: 500px;
}

By setting the left and right margins as ‘auto’ and the left and right as 0, the menu is positioned perfectly in the centre of the page (but at the bottom, of course) and the width of the actual menu bar is 60% of the screen, leaving 20% at either side. I set the background colour of the menu bar to the same green that is used on the buttons rather than white as I felt that with a menu like this it is easier for the user to see the menu when it is not white as it’ll be obvious why text is scrolling behind it. To get the curved effect on the top left and right corners, I set the border radius to 500px.

The code to activate the hamburger menu is exactly the same jQuery script used on the Storehouse site and also in turn on Nellie’s Nursery Prototype 2.

Unsurprisingly, since its media queries are based on those I wrote for Nellie’s Nursery, the hamburger menu becomes active and the bottom menu becomes visible at 1000px wide and less.

Below is an animation of the hamburger menu system running in Elebase 3.

As can be seen from the animation above, the current page is still highlighted on the menu bar and the function that tells the user that the feature is not available in the prototype is still present from Mobile Prototype 1 (which remember this is essentially a modified copy of).

The menu button doesn’t change to a cross anymore. I don’t think it needs to change since it should be obvious to the user that to close the menu they can simply press the menu button again. If there was going to be a cross icon to close the menu I feel that it would probably need to be located in the upper right corner of the menu, which ruins my ergonomic idea of being able to use the prototype with one hand on a smartphone.

Wednesday 7th March

Today was about looking at media query and responsiveness. The 5-point media query code I wrote is generally very well-regarded as being fluid and displaying well on a range of devices. I put a lot of time and effort into writing such a fluid breakpoint system back in February, but with the changes in Elebase 3 the media query needs to be reevaluated to take into account how the new menu system looks on different devices and also fix some bugs found with using the hamburger menu in landscape mode.

Fixing the issue with the hamburger not displaying correctly in landscape mode is relatively easy, however I intend to rearrange the menu entirely when the phone is in landscape mode to help try and maximise screen real estate. I feel that in landscape mode it is probably not terribly practical to have the menu buttons at the bottom of the page because having a menu bar that consumes 60% of the horizontal width will be quite large. Instead, the menu probably needs to be relocated to the left or right of the device and the menu will need to slide out from whichever side the buttons are on. The buttons in the menu will need to be made smaller so that they all fit on the screen properly. At the time of writing this, I have not yet coded this or made a clicakble wireframe of it in Axure, but I have sketched out how it could look.

The logo would move so that it is not obstructed by the menu and the feature image would move to the top of the page and act more like a header. The hamburger menu itself would occupy half of the screen width and 100% of the screen height. The real version would have enough room for all 6 buttons – unfortunately on my quick sketch I didn’t make the menu big enough!

Coding this will definitely be done before Elebase 3 is tested on the 16th.

At the moment I have been focusing on making sure that in portrait mode the buttons all fit into the hamburger menu correctly. Setting the height of the menu to 50% and the height of the buttons to 12.5% whilst the screen width is below 1000 pixels wide seems to work fine when on a desktop computer resizing the browser, but when emulated on some mobile devices including an iPhone 6, 7 and 8 the buttons are too big and bleed behind the menu bar.

I wrote a lot last week about testing on emulators (like shown above) and on actual hardware. As of the time of writing, I have not yet tested Elebase 3 on actual hardware so it will be interesting to see how or if this works. The solution is to make the button height smaller and also make the text smaller. This is something that will need to be played with.

It seems to work fine when emulated on a tablet display, like an iPad shown below:

So clearly what needs to be done is in the media query breakpoints the height of the buttons and the size of the font in the buttons needs to get smaller so that it fits better onto smaller screens, or the height of the hamburger container needs to be increased.

Time management

The deadline for the Storehouse website is coming very soon and my team today needed me to dedicate some time to finalising the article templates for the site, so that is what I spent most of today doing since I had spent a lot of time yesterday on implementing the menu system into Elebase 3. Interestingly, the article HTML pages for Storehouse also share code with Nellie’s Nursery – the text container used on every page of Nellie’s Nursery is also used in Storehouse to house the articles since it is centre-aligned and falls nicely beneath a hero image. The differences are that the Storehouse container does not have the curved edges and it is a little narrower, but otherwise it is exactly the same.

Time management is certainly something that balancing the development of Nellie’s Nursery and Storehouse is teaching me. It’s also teaching me to be efficient by trying to recycle code from each where possible to save time writing new code, but it has meant that recently some days have been much more focused on Storehouse than Nellie’s and vice-versa.

Talk from Marc Merrywest from Made agency about building relationships with customers

Recently the university has been running a series of talks called ‘Platform’ in which a local professional comes in on a Wednesday afternoon and delivers a presentation about an aspect of business. Often I don’t go to these talks because they’re aimed at those who want to start their own businesses and go freelance, but being a freelancer isn’t an ambition of mine. Having watched my father set up his own company aged 42 some 8 years ago now and how he initially found it hard to get going despite being in the industry for around 25 years prior and knowing hundreds of contacts, the thought of starting my own business with no industry experience or contacts frightens the life out of me and I think it’s a bit unambitious and certainly very stupid to do it straight out of university, but each to their own. My father has done absolutely fine for himself, he feels happier working for himself and his business has been a success, but to this day he still sometimes worries that there isn’t enough work, or that there’s too much and he’s always saying that he could never be employed again as he is too used to be being his own boss. I’ve always wanted to be employed by big names, throughout my life I’ve dreamed of being employed by everybody right from the RAF to National Geographic to Microsoft, just for the job security and I guess the bragging rights really.

However, today it was about building relationships with customers which interested me since I am working for a customer on my project right now. The last time I attended one of these talks I found the presentation to be pretty interesting and well-delivered, but not entirely relevant to my work which I was disappointed by. This talk from Marc this afternoon was a little more relevant as he talked about knowing what your target audience really wants and how to keep them coming but I found myself having to disagree with his main point which was that ‘goods do not exist – everything is a service – so just focus on service’. From my AS level economics days, I can recall that goods and services do in fact exist separately, with goods being tangible items and services being activities that are provided by people. The two need to go together (generally) to form a successful product or company. Marc’s argument was all to do with ‘service-centric logic’ and that when you bought a product, you weren’t buying the product, you were buying a service that that product could provide. It was hard to get your head around what he was on about until he gave an example: ‘when you go and buy a drill, you don’t buy the physical tool [the drill], you buy the hole that the drill can produce for you’ (thus implying that the drill was not a good, but a service, the service being the drilling of the hole). Another example he gave was when buying art to place on your walls at home, ‘you are not buying the physical painting(s), you are buying the emotions/reactions that you have to that art or buying that art to improve your home’, turning the piece of art into a service (the service being the reaction it gives you or the improvement of your home). In my mind, this logic is flawed because the ‘service’ that he was talking about in these examples cannot be performed until the good has been acquired. How do you make a hole in the wall without a drill and how do you expect art on the walls to improve your home without having the art to do that? I think the idea was he was saying that service is very important to keep customers and build a great relationship with them – and it is! But you don’t need to start thinking about goods and services in this awkward manner to realise that.

Overall then I found the main idea behind the presentation a bit confusing and I don’t follow ‘service-centric logic’ at this point in time, but maybe in the future I’ll go away and research it a little more and find a better explanation or see what I am missing. For the time being my views are still very set in the A level economics ‘a good is a good’ and ‘a service is a service’ and ‘the two go together to produce a great product or company’ logic. Sometimes keeping theories, especially economic ones, simple is the best way.

Marc’s presentation style however I did completely understand I liked! I liked the use of an online service called ‘sli.do’ which allows the speaker to create questions and polls online that the audience can answer by visiting sli.do in the browser on their device and typing in a unique reference code that allows access to the speaker’s questions and polls. It was a great way for people to voice questions and opinions on the talk – nobody likes to be the one in the audience who puts their hand up and talks! The next time I do a large presentation or feel that the need for something like it is there, I might look at using something like sli.do. For a presentation like Marc’s, sli.do was perfect.

Thursday 8th March

Today I addressed another criticism found in my earlier prototypes: the tiles system. Some users said the tiles were too big and made finding information difficult and easy to miss. The ‘Masonry’ tile system as I called it was first written on Thursday 8th February and whilst I thought it was good at the time, the problem with it is that it doesn’t really work very well. It’s meant to display the tiles in a grid on the desktop site and stacked on top of each other on mobile devices. Unfortunately, no matter what the screen resolution is it just displays all of the tiles as boxes that consume 100% of the page width.

In Elebase 3, the Masonry tile system is deprecated and replaced with a brand new truly flexbox framework that I’ve written called ‘Tiles’, which is much lighter and actually works properly. The CSS for the Tiles framework is shown below.

/*Nellie's Nursery Tiles*/

/*Default styling for all tiles, additional properties can be added using the CSS classes below*/
.tile {
    border-radius: 25px 25px 25px 25px;
    padding: 15px 15px 15px 15px;
    margin: 10px 10px 10px 10px;
    text-align: justify;
    color: white;
}

.tile.green {
    background-color: #aed2a7;
}

.tile.yellow {
    background-color: #fbc477;
}

.tile-img {
    max-width: 100%;
    height: auto;
}

/*Tiles responsive*/

@media ( min-width : 1350px ) {
    .tile-container {
        display: flex;
        flex-wrap: wrap;
    }

    .tile {
        width: 45%;
    }
}

The tiles themselves have exactly the same properties that those in the Masonry framework had and even have the same ‘green’ and ‘yellow’ classes that can be added to the ’tile’ class to change the background colour from green to yellow, but now the framework supports responsive images within the tile by placing an image in the ’tile-img’ class and a media query is employed to make the tiles occupy 45% of the screen if the screen width is above 1,350 pixels. This means that the tiles now appear as squares on the desktop site, like they should have done with the Masonry framework.

 

1,350 pixels is wide enough to comfortably display all of the tiles with little display issues. I may add more media queries to the framework in the future to keep the grid on displays that are even narrower by just making the tiles a little narrower. This would fully address the criticism of the tiles being too big and not doing their job, which is to make information stand out and be more visible.

Introducing Elena Lockyer to Axure RP

I like to teach people how to do things if it will help in the future and if I can make sure that they aren’t going to turn around and either get me to do all their work for them, or teach them a skill that they might use against me, for example takingt that skill and use it to beat me in something competitive (that could be getting an internship, a job or a better grade than I). Generally I am quite free with my knowledge and unless I think you’d do either of those two things I’m usually happy to help. I usually also like it if I can learn too or the person I am working with can exchange some of their knowledge and/or experience with me.

I have a friend in Year 2 Graphic Communications called Elena Lockyer (who will be testing Elebase 3 for me on March 16th) who wanted to use some prototyping software to create an interactive website for her latest assignment, which is to demonstrate the ‘six degrees of separation’ theory that suggests that everything and everybody on the planet is linked somehow, some way, by no more than 6 different steps. She was tasked with finding 6 links between Abraham Lincoln and Marie Curie. She wanted to demonstrate these links using buildings relevant to them and show it in an interactive web page, allowing the users to click on the buildings to bring each one forwards and tell you some information about how each one is linked to connecting Abraham Lincoln and Marie Curie using the six degrees of separation theory.

Originally she wanted to do it in Principle, but not being a Mac user I didn’t know how this worked, so I suggested that she used Axure. At first she was a bit unsure and thought it would take her a long time to learn how to use the software, but I taught her how to use cases and rollover and mouse click events to change the size, location, opacity and visibility of objects in Axure and she soon picked it up really quickly and in no time was able to do it all herself and even learned new bits of the software! After an hour she was doing it all herself.

I don’t have the latest version of her work, but below is a quick video of the older version that we started working on running on AXShare.

She later messaged me asking whether events could be done conditionally, which got me researching how to use conditions and variables in Axure which was interesting. This is why I like teaching people new software – it gets me to delve more into it too! Admittedly I already knew a bit about the different actions and cases in Axure, but I didn’t even know that you could use variables to make things happen based on conditions. It’s great and will help me!

It was also reassuring to see Elena picking it up so quickly and then going home, working more on it and learning even more new features and then asking more questions. I think I must have a fairly decent job at teaching her the basics of cases, conditions and variables in Axure! Judging by her thumbs up in the video below she was pleased with what she was able to do with Axure!

Friday 9th March

As outlined on my Gantt chart, a busy day! I knew that I had a lot of other things today when I made the chart last week, so I deliberately didn’t schedule anything in particular for this day. I spent most of the day in a meeting with Tom Haczewski at The User Story (a local UX consultancy) about using VR at an event we are running at the University of East Anglia in a few weeks about UX. We aim to get Year 10 (aged 14-15) students interested in UX by getting them to redesign a popular app, such as SnapChat, and make it a ‘VR experience’. This is a real problem that UX designers are facing at the moment – we have this new and exciting product (VR) on the market now and consumers are beginning to buy into it, but there are still no real foundations or guidelines for designing apps for this new platform. We want to see what 14-15 year olds can do based on just a few minutes experience using an Oculus Rift VR headset which are going to let them use to see how a VR headset works, what buttons there are for the user to press and what being in virtual reality is really like!

Going forwards

The Storehouse site and Elebase 3 both need to be finished on the same day. Luckily, Storehouse is nearly done (the beauty of having several people contributing to the same project!) which will leave me more time to focus on Elebase 3 next week. In my mind, the two big tasks to try and complete next week are refining the media queries even further and write the media query for landscape orientation and start to put actual copy text and images onto the site pages. I may even try and build a couple of additional pages, even those these are not required for testing. I also need to reach out to my six testers at the beginning of the week and just confirm with them that Friday is still a good day for them to test. If any of them can’t do it, that still gives me a few days to find somebody else.

Bibliography

Medley, J. (2017). Navigator.vibrate(). [online] MDN Web Docs. Available at: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/vibrate [Accessed 11 Mar. 2018].

Buckler, C. (2013). How to Use the HTML5 Vibration API — SitePoint. [online] SitePoint. Available at: https://www.sitepoint.com/use-html5-vibration-api/ [Accessed 11 Mar. 2018].

Ilias Ismanalijev. (2013). Learn how to vibrate your mobile phone on the web using the vibration API. [online] Available at: https://illyism.com/journal/vibrate-mobile-phone-web-vibration-api [Accessed 11 Mar. 2018].