Portfolio – Page 2 – Robyn Veitch

10 August 202012 May 2021 / #Algorithms

Games of Life

A story of repeating patterns of behaviour.

The Game of Life by the mathematician John Horton Conway in 1970 is a zero-player game based on replicating cellular autonoma. this post details three different versions I made and the reason why for each.

The Game of Life presents an N sized grid where each cell has two possible states, alive or empty (dead). With each game tick, the cell can change state or remain as it is based on the number of cells around it. A cell with too many neighbours will die of overpopulation, a cell with too few will die without ‘civilisation’ to sustain it. Cells with the right amount of neighbours will come alive and so on.

In this way, the Game of Life, a Turing Complete model in which each generation is a direct result of the previous state, is the perfect challenge for a state-building exercise.

My first version took a number of weeks, built in React, it helped me learn fundamental algorithm concepts and state-management techniques which would come in useful later.

I revisited this project again years later, reproducing it in a couple of hours, determined to make a cleaner, more robust rendition. At the time I was working with WebGL and three.js, so went back one more time to create a 3D game inspired by the 2D Game of Life.

I’m going to take a ‘poking fun’ approach to talking about these, I believe a little bit of mocking you’re old work is good for illustrating how much has changed since then, and appreciating the quirks of the learning process.

Remember kidos, in learning, there’s no such thing as “bad code”, just code that hasn’t seen growth yet.

Version One: October 2017

This original game, submitted as part of the freeCodeCamp challenge, came straight after the Recipe List and came with a steep learning curve for me.

I knew that I needed a table-like layout for rows and columns, I was familiar with using array’s and .map() but was yet to learn that you could make arrays of JSX and just… dump them in where you need them. I thought there was something magical about an inline array.map. 🤷‍♀️ This lead to some interesting patterns such as creating an N-sized row or column with and N-sized array in state.

I don’t miss old react state initialisation

<Table /> acted as the game renderer and controller, a pattern which would stick in future projects. It’s state held a ticker which would advance by one with each generation. It rendered a table by looking over the arr state item above twice (you were locked into square layouts) and rendered <Cell /> components.

Thankfully I was saved any ‘out of bounds’ errors (in which a cell on the edge tries to check a non exisiting cell) due to the function checking if the key exited in an alive state, and then checking a second time if the key existed in a dead state. In both cases the query for, say “col–1-row-21” would be undefined but no further value checking would take place.

Following the idea that “components should be self contained”, each <Cell /> had it’s own internal life state (nice)… and then on mount, writes this state to a ‘global’ object (i.e. outside the react tree) (not nice) with the following format string as a key: ‘”‘ + “col-” + this.props.colId + “-row-” + this.props.rowId + ‘”‘. 🤮 Don’t ask me why the quote marks are in double brackets because I cant remember.

Cells each had a method to look at adjacent cells in this global object and calculate their next state, which was hard coded because ofcourse.

The last anti pattern was that this function was called when the lifecycle method componentWillReceiveProps was called, i.e. when the ‘tick’ being passed down from the board went up.

Now this idea to tick a game forward in itself isn’t too bad, though it should have used componentShouldUpdate and checked that the new tick was changed. The issue here was that every cell, updating itself, was reading and writing from the same object. The cell does not know how much of the board is from the previous generation and how much form the last. Also, the fact that the globalObject existed outside the react app meant that it existed outside of the application lifecycle structure which could exacerbate this issue.

Remarkably though, it works most of the time.

Somehow, unless my machine is running slower than usuual, the cell updates sync in such a way that the game behaves as it should. the submission was accepted but this always bugged me, it haunted me, it’s remaking was inevitable.

Takeaways

A big thing I took away from this project that I hope could benifit others who may read this is that this potential cell de-sync issue was not enough to wreck the project. The code is duck-taped together in so many ways, its highly innefficient and jumbled but it works.

Often times I see people who achieve things and don’t allow themselves credit becuase they believe they somehow cheated or missed the point of the project. Its a part of imposter syndrome; they think that there is some sort of universally accepted correct structure that they were supposed to find but didn’t and are soon to be revealed as a fraud.

In my view this is how we get into innane discources such as “is HTML a programing language” or “this site design is invalid becuse you used a CSS framework”. In industry, clients generally don’t care whats gone on behind the scenes, they just care about the specification and the end result. To quote my favourite TV show, if you are asked to make somthing which behaves in a certain way then…

Coding isn’t the thing, its the thing that gets us to the thing.

The early prototype. https://codepen.io/Oddert/pen/OOLKzW?editors=0010

Final submitted version. https://codepen.io/Oddert/pen/POwgdP

Version Two: April 2019

It took longer than I thought for the urge to remake the game to finally take hold (other stuff took precedent).

This new game was built with create-react-app and included Redux. This time, the store had a two main keys board which contained data relating to the board display and control which controlled UI elements (in the end this was only used for the ‘paint’ mode, allowing users to write to the board).

The board was a two dimensional array with cell objects inside. Each cell object stored its x-y position and an ‘alive’ property. The reducer for this section only had two actions, one to manually change the state of a cell (for painting) and one which would loop over the whole board, calculate the new state for each cell, then write this new state to an entrely new board array, thus achieving feed-forward imutability.

The <Board /> class had two properties, one to generate rows by calling the next which would generate cells. <Cell /> classes still performed the check individually to see how they should render and would listen for mouse events to paint the board.

And that’s it, cells update when they need to, React takes care of that, the controller component dispatches to tick the game forward, and the files are simple and light ~~apart from the enormous bundle size of create react app~~.

The quickly-finished version two with a clean edge less look.

There were still questions as to whether performing the board loop calculation within the reducer violated Redux’s pure function policy; that reducers should be pure functions and do little work. Despite this, the function would produce the same outcome every time and has no side affects so it is still pure in that sense.

Regardless, this was the remake that I had wanted to do since forever, and it only took a couple of hours, as opposed to approximately a week for the previous.

But I wasn’t finished.

Version Three: May 2019

Around this time I had been investigating WebGL and three.js for a potential project with Matter of Stuff, where I was an intern for my Diploma in Professional Studies (DPS).

See the Pen KYREdx by Robyn Veitch (@Oddert) on CodePen.

One of my little experiments involved creating a ‘voxel builder’, a simple grid space where you can place blocks in 3D.

I took the board state, extended it to a three dimensional array and wrote a function to map to the 3D grid space. I extracted the looping function and created a simple adaptation to run outside of React-Redux (which this project does not use). Lastly, I modified the rule set to return an alive cell if the number of neighbours was as follows: 5 <= num <= 9.

The result is this, a fully 3d rendition of the Game of Life. The rule set could use tweaking given that the cells tend to bubble outwards and oscillate around the edges. And of course you do not benefit from Redux’s immutable patterns.

Never the less I was pleased with the result which went on to influence a range of projects which took place thanks to Matter of Stuff.

6 August 202012 May 2021 / #Client Work

Page Block System | Matter of Stuff

Following on from the MoodBoard system, as part of the Matter of Stuff site redesign, I implemented new pages using a fully customisation page editing system to give the team full control over their content.

When the Matter of Stuff core team set out to design their site, they wanted an outcome that reflected the bespoke, high-end, and established company which they had built over the past season.

They needed something which not only perfectly reflected the company they are now, and could be updated instantly to reflect changes dynamical, given the rate of expansion, events, new flagship pieces etc that they engage in.

In other words, they needed a site that would keep up with their pace, without having to wait for a developer to be available. Customisability and agency to control every aspect of the design was imperative, with one word at the centre of everything; control.

Working with the visual design created by Daniel Stout, a freelancer at Matter of Stuff at the time, I suggested using the Guttenberg Block system on their WordPress instance and fairly recently been adopted by WP as the default editor.

The result was a custom made series of 20 WordPress Blocks, created with the Block Lab library. These Blocks, which included a mixture of basic components (headings, paragraphs, page breaks etc) and custom layout sections.

The ‘About’ page showing how it was split into blocks. Some blocks like the ‘Icon Call To Action’ are self contained and use the built-in columns system to create layout.

This system would be reusable enough that creating new pages or radically re-arraigning a page layout could be done in minutes, without needing to worry if everything conformed to the Matter of Stuff design style.

Every Block had as many options as possible for customisation of not just all of the content, but also all aspects of layout and display.

Most Blocks had the same basic features to ensure consistency in editing with Block-specific features added on top.

For instance, most blocks featured a wrapping element which defined the element’s position in the document flow. Then, there would be a container to provide the layout for the actual content (unless the contend is full-sized), CSS flexbox was prioritised over grid using patterns of cascading pairs. That is to say that, if four elements are in a row, this would be two flex boxes nested inside another flex box. This meant that mobile layouts were usually intuitive but also allowed MoS to swap the left-right top-bottom alignment of each “level” of content as show bellow.

Shown here is the ‘What We Do’ block which principally exists to place text next to an image in equal weight. Here you can see how changes made to an individual block in the editor can alter it’s layout.

Mobile view compassion for the ‘About’ page

Paragraph and Quote blocks used on the ‘Manifesto’ page.

The ‘Procurement’ page showing a custom image gallery where, in addition to the ususal layout changes, the team had options to change the ratio of one image to another.

With the Dual Image Block, the team could enter a ratio using a set of standard formats (e.g ‘2 : 1’, ‘3/5’, ‘2 |4’) where my code would sanitise the inputs and use them with flexbox to change the ratio of each image accordingly.

This carousel showed various gif images of each of the MoodBoard features and was designed in the style of the MoodBoard itself.

While exploring options the team did discuss the option of building the site with a page-builder like Elementor.

I advised them to take this option given that I was able to replicate all the core aspects of customisation they would be looking for without having to pay the annual fee for the editor.

In addition, page-builders are a great and accessible options for people who don’t mind a bit of compromise; there will always be design ideas which the framework does not support and, the majority of the time, there is a perceptible feel that the result is “off the shelf”.

For a company like Matter of Stuff, we agreed that, short of fundamental technological limitations, no compromise should be accepted.

Nothing should feel pre-packaged.

31 July 202024 November 2020 / #Games

Simon Says

A virtual Simon Says game replicating all the functionality of the physical toy. This project was useful early on for learning about time-based functionality, HTML sounds, and tasteful machines.

View Code Live Demo

Simon says is the classic game where a sequence of lights and corresponding tones is played at you and you repeat the sequence back to progress to the next level. Starting at one beep, every level adds to the sequence building up until you eventually trip up and cannot remember what comes next.

This might seem like a simple device to implement, but the further you look, the more complexity you have to account for in terms of not letting people click while the sequence is being demonstrated to them, accounting for the “strict” setting and implementing a power on-off switch. What’s really being asked of you, is not just to deal with sequenced events, but to build a multi state machine to dictate what happens when.

It was also a fun chance to develop some aesthetic and layout skills, I wanted to inject some skeuomorphic styling on the buttons, took care to match the font on the front and spent some time trailing styles to make the score indicator look like a real digit display to really bring up memories of using little toys like this.

31 July 202024 November 2020 / #Social

PinApathy

A Pinterest.com clone built with React on an Express back-end. Authentication by Passport.js using both local and 3rd party oath2, Mongoose and MondoDB as the database, hosted on Mlab.

View Code Live Demo

The react-masonry package works to animate items efficiently into place in a way that is not possible with just css

The app replicates Pinterest’s masonry layout using react-masonry, allowing cards to create that cobblestone look, slotting into one another. Pins can be re-pined by new users, added to boards and have likes and comments posted.

The front-end was built using React-Router for pagination and to split the various aspects of functionality.

An open pin with it’s source link credited and some comments underneath

The name was a joking placeholder on the observation that Pinterest’s once usable format was heavily modified and moved from it’s original format in the name of increased advertising and ‘engagement’. “Interest” meaning more click through’s instead of meaningful curation is replaced with “Apathy”.

A user’s home page showing their boards and the three most recent pins

31 July 202024 November 2020 / #Social

Straw Pole App

A relatively early project, a full MEEN stack (Mongo, Express, EJS, Node) app to allow users to post poles with simple, bold visualisations displayed to others.

View Code Live Demo

The landing page listing active polls

The app used an Express server with Passport.js for authentication and followed strict CRUD principles in the route layouts. Pages were templated from EJS partials and bootstrapped using Semantic UI. Poll results were visualised using D3.js.

This was a good project for feeling out if a CSS framework was something I’d like to use more of going forward (nope as it turns out) and developing clean code practices.

Another, larger poll with custom option capability

For instance, at the time I didn’t use Mongoose promises and was not yet using ES6 syntax so there’s a lot of ‘pyramid code’ yet the app is still clearly readable, something to perhaps take on board given that some later projects, while far superior on a technical count, are difficult to reverse engineer.

An example of callback-based Mongoose leading to pyramiding; every nested callback adding to the indentation

30 July 202024 November 2020 / #Games

Rouge Like React

The final project on the old freeCodeCamp curriculum, a seemingly gargantuan task to push the React framework to create a procedural generated rouge-like dungeon crawler.

View Code Live Demo

This was my second really big React project and also served as my first introduction to Redux.

The game is grid-based, displaying the user in roughly the middle of the map, rooms branding off in various directions. The player’s view is obstructed by default, showing only their immediate surroundings. The player can move around, pick up items and health packs and fight enemies by ramming into them, every time calculating damage for the enemy and player.

The Main game screen with darkness enabled.

The game progresses through levels which are generated completely randomly each time with a set, or slightly varying number of health packs, enemies etc. The player can progress their weapon to deal more damage on each hit of the enemy and prepare them for the final boss (a really tough enemy!)

The game was balanced to make it actually challenging to play; there is a genuine trade off between getting more XP, health and risk factors going into the next level. The collectables and diminished view port incentivise exploration of the auto-generated labyrinths.

Games like this and the Game of Life are brilliant for learning fundamental data structures and data-visualisation methods in an intuitive way. Years later I found myself learning about such data structures, not knee-deep in C or Java, but by relating what I was reading back to this project.

The core data structure is a matrix; a two-dimensional array representing the rows and columns, each entry holding cell data. A single Board.js component is tasked with itirating over this array and painting a cell a particular colour, off-white if the cell is a floor, blue if it is a wall etc.

React then handles updates to this board by re-rendering after mutations apply to the array. This was a great project to learn Redux with, given that it is an ideal use case for Redux’s feed-forward immutable patterns.

Given that nothing on the board moves independently, there was no need for a sequencer or ‘game tick’, the only actions come from the player moving, this is one of the realisations that helps to break down the problem early one; you only have to listen to four key press’es effectively.

On player move, the action-creator looks to the cell the user wishes to move to and decides an action based on what is found there, it then calculates the next state of the board and updates it all at once.

The biggest challenge with this project was dynamically creating each level, every level, and every game had to be unique. A function was created that followed this basic process:

The centre of the board was found, a starting square of 9 x 9 was turned into ‘floor’ (the default cell being ‘wall’). This was designed to ensure there were no proximity collisions on level load, hoping that the user would not notice the centre of each map was the same.

A function for generating a single ‘room’ took in a direction as an argument and decided on a size (width * height) within constraints. Then, in the direction dictated, using the previous centre as a starting point, it would move it’s pointer a random number of cells across (within constraint). Then in the perpendicular direction it would also move a random direction but only to a maximum of two cells.

For instance if I was ‘moving’ right, the pointer would move to the right a random around between 2 and 7 and then move up or down between 0 and 2.

This diagram shows how the room generator function to find the new centre would check valid cells and shift in the x and y directions to find the new centre.

This would then give us a new section of floor space which overlaps with the previous (thus extending the room) or, if operated by a wall, a door would be made at a random point to connect the two.

The last thing this function would do is make note if any value was outside of the board boundaries, this allowed the implementation of the last major function; the recursive path generator.

The recursive generator would, for each cardinal direction, keep generating rooms using the previous function, picking a new direction each time, allowing it to loop back on itself. It continues until the data being returned would signal that an outer edge had been hit, and the function would stop. This enabled truly unique levels every time.

All that remains is to randomly place a set number of entities per level; enemies, weapon upgrades, health packs and the exit point leading to the next level. A recursive function is used to do this, randomly picking a cell and calling itself again if that cell is occupied.

the player's status ui showing a joke weapon

I also put some small quirks in the game to give it some personality such as the “you died” screen and the choice of weapons in the progression such as “Rock on a stick” and “The power of React itself”.

This being a project in summer 2017, it was built using an older version of both react and redux which is amusing in hind sight. How remembers React.createComponent({}) ? or lifecycle method based Redux store subscriptions?

Looking back, this project was a key moment in my development career. Sure, the code is highly inefficient and messy by my current standards given that three years have passed as of time of writing. There were also some pretty bad mistakes and antipatterns which I learned from later on such as the un-pure functions called from within the reducer and functions which dispatch also in the reducer.

But the biggest effect this project had was that it allowed me to realise the size of a challenge I could overcome. Before starting, I had taken a break from code because I had not idea where to even begin with this challenge. I believed I would quickly burn out or waste weeks worth of time only to eventually fail, thus validating my imposter syndrome.

I can’t remember what exactly what let me get over this self-imposed block but I do remember the thought process, bringing together all of my experience and knowledge of algorithms to that point, and experiencing inspiration about the issue of procedural generation which lead me to start.

30 July 202024 November 2020 / #Productivity

Direction Planner

The Directions App was an attempt to reconcile challenges around balancing complex responsibilities and needs in day-to-day life, inspired by a personal need.

View Code Live Demo

A new take on the classic “work life balance” dichotomy, the Directions App presented all actions and responsibility as equal, and aimed to offer ‘mindless’ task direction without simply creating to-do lists.

This was a significant project to me, it was my first proper Redux application and allowed me to hone in React knowledge that I had previously only uses in fits and spurts.

Much later on, the notion of non-coercive task organisation and my findings from this project influenced the “traffic light system”, a component of my project Boots & the Future of Wellness.

View the live demo and repository with the links or read on to learn the backstory.

Backstory

Ok so we’ve all built To-Do lists, you learn the basics of a new MVC framework and can easily test your work. Then maybe, while continuing your learning, you make a version with data-persistence, probably with localstore or maybe something like Redis. Then if you really want to, you can set up a database and save the data permanently which is a great way to practice React-Express integration.

If you desire more in-depth productivity and planning tools there is no end or free software available to help you ‘do more, faster and smarter’ or ‘take control of your work’ or ‘plan every last detail’.

I found myself in a personal quandary. I, as ever, had a lot going on in my life. I was slowly coming to the realisation that just powering through; working endlessly, pushing myself beyond limits, just wasn’t working. Day’s blurred into one endless stream of “stuff”, with five things demanding my attention at once, an endless wish-list of things I’d like my life to have (or not have) “once this is all over”.

I would burn out, I was kept physically fit by running about all day but my health took a beating with regard to diet, sleep, and of course, mental state.

You are a machine

Everyone has at least some experience of living like this and maybe gave or received advice that sounds something like “You’re not a machine, you’re a person, you need time to breath and do other things”. I agree with this sentiment broadly but I think it misses something: a ‘machine’ of most types does not run endlessly, without “rest”, or without “breathing”.

The definition of machine is broad but lets generalise of a second, imagine an abstract “Machine”. A machine can run for a duration of time then needs repair. A machine can run at sustainable levels for long periods. A machine can be pushed beyond it’s quoted physical limits but with the cost of quicker time-to-fail or malfunction.

I don’t know about you but that sounds like a pretty good description of a person to me.

A person is a biological system that has needs and conditions with affect their behaviour and abilities in their ‘functioning’, living day to day life. To take some easy exemplars, if you don’t sleep enough, you can put in all the extra hours that you like but won’t necessary be as productive. If you write something while caffeinated it may have a different read to something written in a more subdued state. If you do work while a little tipsy you may find you peak in creativity and inspiration but make sloppy mistakes and quickly drop bellow productive levels.

Here’s one I still struggle with, if you are stuck on a problem, taking time away, rather than trying to power through, can let your subconscious process it in ways you are unable to, leading to faster solutions. As intuitive as it may be to step away while the clock is ticking.

“This is not a task-list”

So how exactly do you balance things when you have five ticking clocks and now, the pressure to do this “self care” thing you just learned about?

You could try a simple planner and a to-do list but these both have the issue of making everything a “task” to finish. Is walking in a park a task? Reading a few pages before bed? What about things that repeat, like if you are job searching and need to do a little every day? Do you continue on weekends? How much do you do a day? How do you measure it?

The Directions App was an attempt at doing just this, it ordered all items with equal weight, utilising a tag system to differentiate them.

Priority: this denotes actual task items, things which need to be completed
Ongoing: this is used for tasks which repeat for a duration of time
Fun: used for recreational activities
Health: used for activities which benefit health and well being
Social: used to section social activities

In this way you could combine which would show items denoted by which filters were active. Looking to do something recreational but also healthy? Turn on ‘Fun’ and ‘Health’. Set some time aside for task work? Use ‘Priority’, and so on.

Looking back

I still have a fondness for this app even if I didn’t actually end up using it all that much after a while. It was a useful way to explore things which exist between boundaries such as something which is fun and enjoyable to do but is still ‘work’. I realised that by assigning everything a tag and grouping them together, I could see the interlink between various tasks but it didn’t work so well to actually designate time, to come up with that magic formula where everything is balanced and just falls into place.

On a stylistic note, it was useful for me to develop emerging styles and layout patterns which would be refined further later on, even if it looks somewhat garish now.

30 July 202012 May 2021 / #Mobile Devices

Emergency Torch

Unit three of the course dealt primarily with design from a user perspective, the torch project was an exercise in applying the design process to an every-day object with particular regard to emotional and functional considerations.

This project began with a simple, incredibly open brief, summarised by it’s title; that is “to design an Emergency Torch”. Being a shift away from previous project which focused on practical manufacturing knowledge, this contextual study left the door completely open for use to define what an “emergency” constitutes, and justify a design response.

An early design concept for a tubular light which holds a position decided by the user.

At the beginning of the project I was of two minds, on the one hand this task was to design within a typology that already exists, and necessitated finding a problem within that typology rather than starting with an identified problem and finding the most appropriate solution. In other words, it is what some would call ‘traditional product design’, object-orientated and consumer lead.

On the other hand, the emphasis on technical competency and refinement of function was very similar to what I was familiar with from the SQA’s preferred methods. This was a chance to really push and refine particular skill sets.

In addition, it offered an opportunity to identify a real problem and conceptualise a design solution which could, if actualised, help people in a genuine way.

In Scotland, engineering practice starts early. This is one of my earliest pieces of design work, a multi function display stand, produced at 13 years old.

My final design solution looked to provide an all-in-one device for survival situations where a torch may be all that the user has left, for example a vehicle crash or sudden natural disaster in a remote region.

Through research I identified four essential resources to have in such situations as being: Ability to start a fire, A survival knife or basic tooling, Energy generation (if any other electronics survived) and, by extension, light.

My final design functioned primarily as a torch with functionality built in to generate thermos-electric power and start fires using solid-state functionality.

Final Presentation Board

Second Final Presentation Board

Reflecting back on the project I was pleased overall with the outcome, particularly with the iterative development of the products functionality and form, however the end solution was a bit ‘Jekyll-Hyde’ in that several typologies had been hybridised rather than their concepts synthesised.

Rather than create a combination of a survival knife and torch’s functionality, I had simply designed a survival knife with a light on the front. In addition, questions could be asked about the efficiency of the thermos-electric generator and the specification of the LED’s used.

I may revisit this concept in the future and take these considerations into account but over-all, the project was a good exercise and extension of the basic skills involved in physical product design.

robyn_veitch-emergancy_torch Download

30 July 202012 May 2021 / #Manufacture

Hold, Store, Display

A project to design a new method of storing and displaying an item for the Arkwright Scholarship program.

As my year group was starting fifth year of high school, Eastwood was given the opportunity to engage fourth year students in a scholarship program.

At the time, there existed the possibility of myself and the other new fifth years also being permitted to take part. Later this idea was rejected, but whilst waiting, I made some progress on the brief given as part of the application process.

The Arkwright Logo.

The brief was very simple, intended for interpretation as much as deliverable outcome, to design an object, no more than 1.5 x 1.5 meters to hold and/or store and/or display another object.

The only other requirement was that a working prototype, or at least a proof-of-concept had to be manufactured and documented.

Design Idea Two uses a micro-suction-cup material to hold a range of flat-backed items while idea one utilises a shape-memory polymer to be fully flexible in use (pun intended).

At the time, this was for me a wonderful chance to apply some new material knowledge and to express and actualise some ongoing ideas which were relevant to my work at the time. Specifically, it was at this time that I was becoming interested in the meaningful impact of product design and moving from a mode of ‘design-for design’s-sake’ and designing products to make a 50th percentile middle class suburban person’s life more comfortable.

Daruma dolls originate in Japan and are used to remind oneself of a goal to be achieved at some point in the future. One of the doll’s pupil-less eyes is painted to represent the doll always keeping one eye on you to make sure you stay true to the goal. Once you have achieved the goal the second eye is painted and the doll becomes a reminder of the journey.

I tried to inject some of this thinking into the ideas by making four of them (designs 1, 2, 4 and 5) adaptable and/or modular, making one (design 3) orientated towards personal reflection and individual-base and one designed to be aesthetically contemporary but aimed at lower cost markets.

I was in the mid development phase for one other the three ideas I wanted to take forward when we were informed that the scholarship was cancelled. I developed idea five through to a prototype and may pick up on some of the others, specifically ideas one, three and five at some point as I believe there is potential in them for a unique design solution.

robyn_veitch-arkwright Download

V1 – React.js

V2 – React-Redux

V3 – Three.js

Version One: October 2017

Takeaways

Version Two: April 2019

Version Three: May 2019

Backstory

You are a machine

“This is not a task-list”

Looking back