uiwalker

[uiwalker]

FINAL SITE

So there we have it, the Project Make project library. I still consider this project to be very much a work in progress as the complexity and size of the project is far greater than I had originally anticipated. 

In any case, you can check out the live version of the site here: 

http://project-make.com/library

Feel free to check out the other pages on the site but please keep in mind the library section was the sole focus of this studio project. Please let me know if you spot any bugs as well :)

[uiwalker]

Hanging line system.

In this video which demonstrates an image grid module, you can see that I���ve developed a system where content “hangs” off the line down the middle, which provides a visual anchor as well as allowing the titles on the left hand side to be more easily scannable. 

It’s somewhat unusual and quirky which I also quite like. Perhaps it won’t make it into the very final design that actually goes live to customers though. 

[uiwalker]

Slideshow

I wanted a way for a teacher to be able to immersively show content to their classes, and I felt a slideshow was a great way to do this, so I built one where the images could be shown in fullscreen, after the lesson content had been covered. 

[uiwalker]

Final top bar

In the end I went with a navigation that can expand downwards to accommodate very long lesson names, but will also shrink when the page is scrolled in order to get out of the way and be less of a distraction. 

[uiwalker]

Top bar issues

My next issue was the top bar, and how to represent all the content necessary up there without taking up too much vertical space. Again, I experimented fairly extensively with different configurations. 

[uiwalker]

Final sidebar demo

This is a screen recording of the live, coded version of the sidebar navigation. The logic required to get each link working properly was an actual nightmare  

[uiwalker]

And of course...

Making sure it works at the touch screen level

[uiwalker]

Project navigation

One of the most challenging and time consuming parts of the design was how to navigate the fairly complicated nested project structure. 

A constraint I was aware of for the final output was that many high schools use touchscreen laptops, so I couldn’t necessarily make the assumption that just because a screen was a certain width, it was being controlled by a mouse. 

This meant that it made the most sense to keep the navigation fixed to the side of the screen, where a hand resting on the edge of a touchscreen laptop would still be easily able to operate it without too much strain. 

However, I did experiment with several different layout configurations for the navigation, a selection of which is shown below. 

As you can see there were quite a few, and I made these in Sketch because at this point I realized it wasn’t feasible to be writing all the logic required to code each variation, it was simply taking far too long. 

[uiwalker]

Component-based design

I wanted to follow some web development best practices with this project, such as creating re-usable components to avoid repeating code that then becomes difficult to maintain later on. 

I built the site using Jekyll, which is a static site generator that runs on the very popular GitHub Pages platform (where the site is being hosted, by the way). 

The nice thing about this was that it allowed me to split the code up into multiple different files that could then be plugged into various parts of the website as many times as I needed to. 

The screenshot below shows the multiple component files that ended up being joined together to create full pages. 

Editing a single component file would update that component across the whole site, much like a symbol in Sketch or a Smart Object in Photoshop. 

All of the images below are examples of components used across the site. 

[uiwalker]

Designing in the browser

While in Russell, I began working on the feature that would allow Project Make customers to purchase courses online on the site. 

The idea is that in order to make the content as accessible and flexible as possible, a user will be able to choose which parts of a project they feel they need and therefore will pay for. 

Essentially it’s like a build-a-project kind of deal, and to represent how this would happen I first wireframed (I didn’t spend as much time fine tuning this one as I did on the filtering system for lack of time) and then began to build out the system on the web. Here’s the wireframe. 

As you can see the idea is provide an overview of the project and then allow users to remove specific parts from the cart. In practice, if we move forward with this idea, the user would be able to remove only those parts that are not “core” to the project, only ones that are considered supplementary could be removed to prevent compromising the integrity of the course. 

The version I designed in the browser came out looking like this: 

[uiwalker]

Progression Session

Around this time we also had a progression session where I shared with the class the slides below 

[uiwalker]

A writing weekend away in Russell

In order to get things moving faster on the project that we had decided to focus on, Demelza, myself and another teacher and Project Make collaborator, Shelane Lomas, spent a weekend away in Russell doing an intensive writing session. 

While we were there we made a series of large decisions, such as finalizing the nested structure of projects: 

Project: 

Stage

Part

Lesson

The two teachers wrote a majority of the project during the weekend which gave me plenty of content to work with when I began building the UI with code. 

Overall I consider it a pretty successful weekend and, although we didn’t end up getting as much done as we had hoped, we came away with around 30 pages of content and documentation for the course modules. 

[uiwalker]

IA problems and scope change

One thing I hadn’t fully grasped was how much work was required just to create a single project - we essentially needed to write entire NCEA-compliant standards for each project. This takes f o r e v e r

What ended up happening then was that I had to drastically change the scope of the project to focus on creating the UI around a single project, rather than the “library” of multiple that I had originally been thinking about and wasting time designing filters for.  

[uiwalker]

Wireframing + designing in the browser

From the beginning of this project, I knew that I was going to be building a real website using HTML and CSS, instead of doing something like a Principle prototype. This was both to set myself a challenge and because the final output for Project Make as a company is a real website so it made sense. 

Initially, my hope with this project was that I would be able to forego the usual step between wireframing and development, which is designing mockups in Sketch. 

I began moving towards this goal by only doing basic wireframing at first. I wanted to understand how a user might navigate their way through the site when there were dozens, potentially hundreds of projects to choose from. 

How does a panicked teacher find a project to teach quickly?

How do you filter projects?

Can you search for projects?

These were all questions I needed to answer (at least I thought I did), and so I began wire framing a filtering system for the “project library” section of the website. 

Using Balsamic (another trick I’d picked up from Benek) I was able to focus solely on the functionality of the elements rather than their aesthetic quality. This was a process that I really took my time with because I wanted to get it right, and I read into several best practices for filtering, looking at examples of how other sites handled it, etc. 

The reason I spent so long here was that since I intended to design in the browser I figured I could just get the wireframes nailed and then sort out the styling with the code. 

As you can see below I was essentially experimenting with various different controls and UI elements, with the intention of running basic user tests with a small control group later on to determine which worked the best. 

However, I feel like I wasted a lot of time here both because I moved so slowly and also because I hadn’t fully got my head around the information requirements of the process. 

[uiwalker]

Information architecture

Probably the biggest challenge with this project was the complexity of the information architecture that defined the projects. It made sense to split projects up into multiple manageable parts, but that meant that we had several levels of nesting, which made information architecture challenging for me. 

I had initially planned to make a large overall schema of the IA, similar to the one shown below that I created for the project with Benek I mentioned earlier. 

In the end though, that didn’t end up happening and I regret not taking the time at the beginning to sort that out properly because it caused me great difficulty down the track. 

What happened instead was that the information architecture became more or less defined by a series of sketches and the way that the course content was written. I’ll elaborate on the course itself shortly. 

The reality of the information architecture: 

Working with a client I discovered that decisions around these kinds of things often happened when we were sitting together and discussing how we each envisioned the product. 

[uiwalker]

Typography

Pretty early on in the branding effort we made the decision about which typefaces to use. We wanted to use two; one slightly more interesting one which could be dialed up for display purposes in editorial and marketing contexts, and one more of a workhorse to do body copy with. 

As a New Zealand company we also liked the idea of using something local (is there such thing as a New Zealand typeface?), so we ended up with Founders Grotesk for display and Calibre for body, both by Klim Type Foundry

[uiwalker]

Dio work

Alongside the main Project Make project, Demelza was also a teacher at Diocesan School for Girls during the majority of the project, and was developing resources specifically for her classes there, based on the premise of Project Make. I was charged with designing said resources, and these documents (a combination of print and interactive PDFs) became a kind of test run for how we might want to design the real site. 

Below are some of the early examples from those designs