Don't wanna be here? Send us removal request.
Text
Final Prototype for INRD601
https://www.figma.com/proto/ykbFDLmdq1ZU8buQwkITvx/Branch?node-id=442%3A282&scaling=scale-down
0 notes
Text
Final Component Library for INRD601

2 notes
·
View notes
Text
Creating the fourth version of Branch, implementing a visual design system based on G’s feedback
Now that we have a solid conceptual system in place, it’s come to creating a visual design system to manifest it. G’s suggestion after seeing our working prototype was to start creating a visual system where everything was related, as it helps build a visual rhythm which users can draw upon and enhance the app’s usability. We already knew what our main user pathways were, as well as an approximate layout for each of the pages within them. This was a very helpful foundation to build off, because we already knew what needs an atomic design system would need to fulfil within Branch. Building off the rough prototype screens, all of the main pages already had a margin on the right, which I decided to call the trunk. The trunk has a width of 52 units, and this seemed a good basis to build the rest of the system on. Each distinct element on the page is the size of one trunk width, and for the purpose of explanation, we’ll call this length “t”. Giving every element uniform sizing helps create that visual rhythm, which users can draw upon to distinguish the different elements which make up each page. We could then start to create a consistent visual language by also sizing the individual parts of each element relative to “t”. Now we have a library of different components which we can combine in different ways to make layouts that will reliably use the same visual languages and rhythms.

Each time we show the title of a page, the cap height of the type will be ½ of t, and it has ¼ of t’s worth of space on the top and bottom. Whereas if we’re showing the title of a branch, the cap height of the type will be 1/3rd of t, with a 1/3 of t spacing either side. The branch and song names are indented by ¼ of t, helping create a visual hierarchy between the different elements on a given page.

The buttons and text input forms are also guided by their relation to that length of t. All the text boxes and buttons have a height of t, and when creating the components to make the app, they include spacing relative to t, meaning we can easily construct new pages by combining components, and knowing the spacing will be consistent with the visual language and rhythms we’ve already developed.

We also added some other minor changes to help enhance usability. The icons on the navbar are now highlighted to reflect what section of Branch the user is in, helping reinforce a sense of place within the app. We updated the explore page to fit more with our original concept of combining twigs to find new music. We could also use the newly developed visual system to make it feel more congruent with the rest of the app’s design.
2 notes
·
View notes
Text
Developing the third version of Branch, based on Raul’s feedback
On Monday, we showed Raul our current prototype in order to get some feedback. Raul noted that the system we’d devised of twigs, branches and a tree was good, but could pose difficult for new users to understand without having it explained. Our solution for this was to create two new user pathways which are presented when opening the app: one with a tutorial for how the system works, and another for people who are already familiar with it. The tutorial explains to new users how twigs are added to songs, twigs are combined to make branches, and branches can be viewed in the Tree or the Forest. Most users of music players will already be familiar with these elements, since branches function the same as a playlist, and twigs function the same as hashtags on other social media, but the important part for users to understand is Branch’s unique terminology, and the connected hierarchy of those elements.
We also redesigned the home screen, after Raul pointed out that the two coloured halves indicated two separate scrollable areas. The new home screen, now called the Explore page, suggests different twigs for users to discover, and also lets users choose multiple twigs and see the respective branch. This is based off our original idea for the “search” function in Branch to be a fill-in-the-gaps sentence builder, allowing for combination of different twigs.
We also made a few minor adjustments to some GUI elements for increased usability. The twig colours were lightened to allow for better legibility, and the icon for the Tree was flipped horizontally, to better mirror the look of the user interface in that section. I also added titles to the main screens of the Explore, Tree and Forest sections to better help users figure out where they are within the app.
2 notes
·
View notes
Text
Formative Feedback
Hi Meela Your design process improved compared to project one. It’s great to see the benefits of teamwork. It’s good to see that the way you work is not one-plus-one but a multiplication of both of your design minds. Do focus on that one thing that your app does really well. And please continue with a more abstract way of using your forest analogy. You need the coming weeks to improve the system to become more consistent and more coherent to help the user personalising their collections as your app suggests really well. Detailed typographic skills are key right now. Stay away from multiple features that your app could also do and focus on the design system that you can extract from the screens you’re designing right now. That’s the most important thing. Raul & <G>
1 note
·
View note
Text
Developing a second prototype
The first change we made when iterating upon our initial prototype was changing the colour scheme, due to the palette of the first prototype simply being a placeholder, created when we were figuring out the basic structure of each screen. We wanted the colour scheme to reflect the warm, welcoming feel we were aiming for, so we chose warmer, desaturated colours. To match the feel of the new colour palette for the major GUI elements, we also picked colours for the various twig types from a desaturated gradient.
The next change we made came about from our in-class discussions, and showing others the prototype. Users reported having trouble finding their way around the app and how to find different screens, which indicated we needed to implement a better system for navigation. This led to the creation of a navigation bar which constantly sits at the bottom of the screen. It contains links to the Forest, the Tree and the search, which means users can access these screens in one tap from anywhere within the app. Meela created icons for these links, using imagery which ties into Branch’s visual themes of tree anatomy as well as referencing the logo.
Our initial in-class user testing also led us to consider more elements which would be necessary in a real music player app. We added in the status bar that sits at the top of the screen on iOS devices, in order to factor it into our design process moving forward, since it wouldn’t be useful to design a whole program without considering the conventions of real-world app design. We also added an element to sit just above the navigation bar which allows you to play or pause the current song, as well as giving you the name. This will eventually allow you to see more information about the song currently playing, such as the album it’s from and expanded cover art, as well as an option for adding twigs.
Our next upgrade involved changing the home screen to show a list of suggested twigs which users can browse. This comes back to Branch’s purpose, which aims to help people discover new music. We also made decisions about what typefaces we wanted to use across the app. We chose use Termina Demi for titles and display type, since we felt its letterforms tied in with the natural, organic feel we wanted to achieve. We decided on Glyphworld AirLand for body type, due to it having good legibility as smaller sizes, especially when lots of type is on screen at once.
2 notes
·
View notes
Photo
Formative Presentation
1 note
·
View note
Text
Building the first prototype of Branch (part 2 of 2)
These GIFs show the animated prototype of three main user interactions in Branch: Viewing a saved branch in your Tree, adding twigs to a song so it gets added to a branch in the Forest, and saving a branch from the Forest to your Tree. This is the prototype we showed to the for our formative assessment. next we’ll be moving on to testing this with people and adjusting it accordingly. We’ll also be building up an asset library to have a more consistent look across the whole app.
2 notes
·
View notes
Text
Building the first prototype of Branch (Part 1 of 2)
Now that we had a central idea and function for our music player, we needed to start creating the app itself. One decision we made early on is that we didn’t want to call the user-assigned attributes hashtags. We wanted a short, catchy name, and ideally one which hadn’t been used before. This led to us brainstorming up alternatives, which started the ideation process for what the name of the music player would be, as well as initial planning for the look and feel of the app. One name idea we contemplated was Trove, which means “a store of valuable or delightful things”, and allowed us some nice alliteration with naming the attributes Trove Tags, but ultimately decided against it due to there being a reasonably popular video game with the same name. Originally we had only considered synonyms for attribute, but eventually started exploring the possibility of using other short nouns. Coming across “twig” as a potential name for these user-generated tags, I started thinking about how multiple twigs combine to make a branch, and how branches combine to make a tree. This seemed like it could be a solid conceptual framework to build the app around, providing both a good hierarchical structure to organise content, as well as providing a lot of potential for visual imagery.
I started sketching out a basic layout of the main user pathways of the app on paper. My original concept was to base the layout and GUI around the structure of a tree. I came up with the idea of dividing the app into two main sections, one for finding new music, and another for listening to music you’ve saved. This solidified the decision of using terminology related to tree anatomy. User-assigned attributes are called twigs, and combining multiple twigs generates a playlist called a branch. Your branches combine to make your Tree, a library of all your saved music. The area for finding new music was the Forest (where you would explore other users’ Trees and find new branches). We decided on Branch as the name for the whole app, due to the figure of speech of “branching out” meaning discovering something new, as it fit well with our app’s intent to help people discover new music.


This is where I started drawing on the conceptual framework of a tree to generate ideas on what the app would look like. I realised from my initial sketches that manifesting the graphical user interface and layout in the form of a tree could come off as gimmicky and novel if done too literally, so I needed to either come up with a new system or experiment with abstracting it to the point where it didn’t detract from usability. Thankfully Figma, which I used to start digitising the screens, works predominantly with vector shapes, so I was able to come up with more abstracted visualisations of a tree and its branches.

Firstly I split the two main sections by colour. The Forest was green, and the Tree with saved branches was brown. The green and brown mirror the colouration of different parts of trees depending on their stages of growth. I used this to come up with a place holder idea for a homescreen offering the user two pathways: green to view the Forest or brown for your Tree. The idea behind this was that the brown section represents the trunk of a tree, while the green section represents a forest behind it. Tapping in the brown area will take you up into the tree, to the branches, while tapping the green area takes you to the forest to view other branches. I emphasised this idea using animated transitions between screens, shown in the GIFs in Part 2.
This colour system runs through the entire app, where brown buttons in the Forest indicate the functionality of saving branches to your Tree, while green buttons in the Tree indicate adding twigs to a song, therefore adding it to the Forest. I thought having a coloured rectangle running along the edge of the screen, again representing a tree trunk with branches coming off it, helped create a sense of place within the structure of the app, and reinforced the hierarchy of twigs forming branches which combine to make a tree. Further continuing this visual language, I wanted the screen where users added twigs to look like a new branch being formed. To visually represent a song moving from your saved library to being discoverable by others, I used a gradient going from the Tree’s brown to the Forest’s green. I applied this same concept of a gradient to represent movement between sections in the area of the app which allows you to save a branch from the Forest to your Tree, although because it was moving from Forest to Tree instead of the other way round, the gradient went from green to brown.
Another idea discussed in the ideation stage was getting rid of a traditional search bar in favour of a fill-in-the-gaps sentence builder, where users could combine twigs to generate a new branch full of songs which encapsulated a specific feeling or idea. This would mean we would need to create some sort of system to classify the tags, in order to combine them in a meaningful way later. I’ve created a basic colour code to use for our initial prototypes, shown below. I used Figma’s colour styles to create these, which let you make sure colours are consistent across different elements and pages, also allowing you to change them quickly. I used colour styles for the rest of the app as well, to ensure a consistent feel through the app.
2 notes
·
View notes
Text
Preliminary research on music players
For our second Design Project in IRDN601, we’ve been tasked with creating a design system for a new music player, using the principles of atomic design. In our first session we did some informal interviews over Zoom in groups of 4 about existing music players. After some brief discussion we’ve decided we want to pursue creating a music application which lets users assign attributes to songs, and songs with similar attributes can be used to generate playlists and mixes. The next step in our process is researching whether this method of user-curated organisation is accessible/encouraged by existing music players. We’ll also look into whether similar services exist for other media, and if so, what can we learn from them?
Our first piece of research came in the form of an informal interview over Zoom, between Meela, me and another group of two, Soumya and Zeinab. Meela’s notes of the interview can be found here: (https://zumizine.tumblr.com/post/618147540277329920/music-player-interviewdiscussion-notes). A large part of our discussion focused on features we prioritised as users of music players, and how the players we currently use cater to those priorities.
One feature that was mentioned was Spotify’s ability to generate a playlist or mix based on a specific mood, artist or genre. These premade playlists help the user discover new music and explore what that the service has in its extended catalogue, but curated through a thematic lens. Another feature brought up was being able to create a collaborative playlist, which multiple people could add songs to and listen.
The original idea for our new player developed as finding a way to bring these two features together: finding new songs though thematic connections, but giving the means to decide those themes to the users. Most music services offer playlists based on a central idea, but because these playlists come from the services themselves, it’s likely their content will reflect certain biases based on the service’s corporate interests.
Although Spotify’s premade playlists eliminate the inconvenience of having to invest time into trawling through music to find songs you enjoy, centering the focus on user-curated content would allow users to enjoy and promote music that otherwise might be obscured by bias.
Questions to ask during this initial research
Does the music player allow you to create a playlist based around a central theme?
Can that playlist be seen by other users, allowing them to discover new music?
Can other users add songs to this playlist which fit the theme, allowing for a collaborative process to share and discover new music?
Does the player encourage this?
Spotify
A lot of people mentioned Spotify in our class discussion about music players, and it seems to be the player of choice for a lot of people. We already know Spotify has a collaborative playlist feature, meaning it is possible to use the already-established system to create community-generated playlists based around a central theme, but we want to analyse if the system encourages this.
When creating a new playlist with Spotify, the user is given three options: a title, a description, and an image. These tools could effectively allow the user to establish a theme for the playlist, and act as guidelines for others who want to add to the playlist. However, other users’ playlists can only be accessed directly through their profile, or an exact search of the playlist’s title. And once a playlist is made collaborative, it is hidden from search results.
Going to Spotify’s “Browse” page, where they showcase created playlists, you have an option to explore playlists defined by Genre/Mood, Charts (collecting the most played songs on Spotify), New Releases, and Discover (which recommends playlists and albums Spotify’s algorithm thinks you’ll enjoy, based on what you’ve been listening to.) You’re also given the options to see podcasts, and concerts that are happening near you.
Clicking on a genre or mood will take you to a page offering playlists with more specific themes. All of these playlists accessible through the Browse categories are created by Spotify, although occasionally they invite celebrities to curate a playlist based on a specific idea.
In conclusion, creating collaborative playlists around a central theme is possible using Spotify, but not encouraged.
Soundcloud
When creating a playlist on Soundcloud, you are given the option of a title, and whether to make the playlist private or public. You can also add tags to your playlists so other users can search for them. This functionality allows you to create a playlist around a central theme, and help others find new music based on that theme.
Soundcloud doesn’t offer any options for collaborative playlists, meaning only one person can add songs. However, on their Home page, they advertise playlists created by the community based on specific ideas within a given theme (for example, Study or Workout.) Most of these appear to be centered around an activity, rather than a genre or mood. In conclusion, Soundcloud encourages users to find new music based on a theme decided by other users, but doesn’t allow for a collaborative approach.
Other services for discovering new media based on a user-decided theme
r/___ThatFeelLikeThis
Meela recommended the “Books that feel like this” subreddit as an example of a service that helps people discover new things based on user-assigned attributes. Users can post a picture, asking for recommendations on books that have a similar feeling to what the picture conveys, and other users can respond in the comments. Reddit’s comments system allow users to collaborate easily, almost to create a “playlist” of books by collating all the comments and the photo they’re on. A similar subreddit exists for “Songs that feel like this”, however it doesn’t get used very regularly.
2 notes
·
View notes
Photo

Presentation Slides part 2 of 2
The slides were designed in InDesign. We wanted the stroke width of the illustrations to be the same as the X height of the text. We used photos taken in class with a gradient map applied to keep the colour scheme consistent with the rest of the presentation. The slides were animated in After Effects, then imported into Photoshop and exported as GIFs.
0 notes
Photo
Presentation Slides part 1 of 2
½. Title/ Contents – Meela
Hi everyone. I’m Meela and this is Kay and these are our key learnings. If you look at the contents you might notice that we haven’t included wireframes. This was because we personally felt like we didn’t have a lot to take away from that week. Kay and I looked at what we did each week and these were the topics and conversations that were the most memorable and knowledgeable for us from each lesson. Essentially, highlighting our takeaway points.
3. IA terms - Kay
in the first lesson we learnt about the three concepts that underpin information architecture, which are ontology: which involves defining distinct entities, taxonomy: which is classifying those entities, and choreography: which is making sure everything works together in a meaningful way for the task at hand. as someone who's never worked in the field of information architecture before, i thought these three concepts helped provide a good contextual framework to determine if information was being organised effectively for the task at hand. and this is why we chose to structure our original infographic around these three concepts.
4. What we learnt through website in-class presentation - Kay
Next we analysed the websites and i chose to present blackboard, a website which i found to be perfectly usable, but everyone was quick to point out that it was designed in a way which could be described as wrong, and also bad. it had issues adapting to different platforms, and people found it particularly hard to navigate on mobile devices. this helped remind me that in today's technological landscape, digital design needs to be able to work on multiple platforms, and also that user interfaces always have room for improvement, though users testing them and giving feedback.
5. What we learnt through the card sorting activity - Kay
After learning those concepts in theory, the card sorting activity where we recorded our interactions for the morning provided an opportunity to apply these concepts. First, we defined the individual interactions, which is ontology, then we could organise them any way we saw fit, which was creating a taxonomy for those interactions. then when we had to re organise them for a specific purpose, we needed to consider the choreography: were the groups divided in a way that was helpful for the user, and did the groups work together to create a delightful experience? `
6. What we learnt through the in-class interaction presentation (at hop kiosk, film camera) – Meela
For my interaction presentation I chose to investigate my film camera. Challenging myself with a physical item put me in a position to pay attention to features I could touch and feel, rather than features on a screen. A good feature I noticed was how the shutter automatically locks itself when the camera is closed. A bad feature was how there’s no indicator that tells you whether the camera is on or off. Telling apart the positive features from the negative taught me that something as basic as a camera with one button can also have bad UI features.
7. Typefaces, why choosing the right typeface matters - Kay
When we studied the typeface, i studied one called cooper black. i learnt about its history and the many things it's been used in over the years. now since its been used so many times over the last century, it would seem like a desirable option to pick for pretty much any project, but what i found after plugging it into our original infographic, it didn't work at all. it felt much too informal for the clean professional look we were aiming for. it was also a display typeface, and ruined the legibility when used at a smaller size.
8. Typefaces, talk about the typeface of the presentation as an example – Meela
On the other hand, the typeface I studied, which was Frutiger complimented the redesigned infographic really well. It collaborated well with the content because the type is intended to be formal, professional and clear. This helped us when choosing a typeface for the presentation, because we knew we were after a typeface that illustrated clarity. This meant finding a typeface with consistent X and Cap heights, and consistent stroke widths.
9. Grid systems, why it's important – Meela
Our session about grids was a great recap for me as what I had learnt from the year before has been pushed to the back of mind. A quote that stuck with me from an article was how “a grid is like invisible glue that holds a design together” which I think is an important element to remember when you’re organising information. A moment where we realised that grids are important was when we had to redesign our infographic. Using a grid system created more clarity, consistency, and improved the design comprehension that our original infographic lacked.
10. Grid systems, talk about the grid system of the presentation – Meela
G also mentioned how a grid is “not limited, but enabling” which shifted my understanding of grids. I always saw grids as a barrier, or something restricting, but in fact they’re an aid that help tie design elements together. Using this presentation as an example, we were able to work remotely and still keep consistency with little effort, all from using a grid system. These points really broadened my prior knowledge of grid systems.
11. What we learnt from revisiting the infographic - Kay
We decided to base most of the design ideas for this presentation on the comments people had left on our original infographic from the formative. the was a resounding number of comments that we had too much text in large paragraphs, so we condensed down to bullet points in order to minimise the amount of large chunks of text. people also told us there was a lack of visual elements, so we've created these icons, illustrations and photographs in order to give people a visual anchor for each slide.
12. Le Epic Ending – Meela
We have combined our overall feedback from our formative infographic and our learnings to convey our new understanding of organising information. Basically, what we have done is presented you a deconstructed version of an infographic, so each slide represents a section of our learnings. Overall, this class has been insightful into the UI world and what we have learnt from this class will help us effectively design interfaces that are visually appealing, but also functional.
1 note
·
View note
Text
Typeface Research: Cooper Black
Cooper Black is an ultra-bold serif typeface designed by Oswald Bruce Cooper in 1922, and was created as a bolder alternative to his eponymous typeface Cooper, which he created in 1919. It was very popular in advertising of the 1920s and 1930s, as it’s rounded, “friendly” forms stood out from many serif fonts at the time. As a result many imitations were created, including Goudy Old Face designed by Frederic Goudy, who had interestingly enough had been a mentor to Cooper earlier in his career. These imitations caused Cooper to file for a patent for the typeface in 1930 and two of the others in its family, which was rejected due its similarities to a logo published in a newspaper two year prior to its release. Cooper later sued the Commissioner of Patents and won. Cooper passed away from cancer in 1940. The font remained mostly unused for the next few decades, until it appeared on the cover of highly influential album Pet Sounds by the Beach Boys in 1966. This caused a resurgence in its popularity in the late 1960s into the 1970s, used on album covers such as the Doors’ L.A. Woman and David Bowie’s Ziggy Stardust, as well as in TV shows such as Garfield, M*A*S*H, and the New Adventures of Winnie the Pooh.

It’s use in iron-on patches also led to it featuring prominently in early hip hop culture, as breakdancing crews would use these patches to emblazon their names across clothing. De La Souls album “Stakes Is High” album cover made homage to this.

Once again the typeface fell out of style until the late 2000s, brought about by a wave of 70s nostalgia. The Black Keys’ album Brothers had a cover that featured only text in Cooper Black, and it was used heavily by art collective Odd Future, as an homage to the DIY aesthetic the typeface embodied in the 80s within the context of hip hop.

Cooper Black has a very low contrast in its stroke widths, making it effective as a display type, but not particularly usable at smaller sizes. Interesting features include the slanted descenders on the lowercase P and Q, the slanted counters of the Os and uppercase Q, and the slanted elliptical dots on the lowercase I and J. I think part of this typeface’s continuing appeal is its friendly look, which it gains from the thick stroke widths and rounded serifs.

References:
https://en.wikipedia.org/wiki/Cooper_Black
https://en.wikipedia.org/wiki/Oswald_Bruce_Cooper
https://www.complex.com/style/2013/08/cooper-black-font-hip-hop-album-covers/odd-future
https://eyeondesign.aiga.org/cooper-black-never-went-out-of-style-so-why-does-it-need-a-redesign/
https://vimeo.com/31237546
https://cite.case.law/f2d/38/852/
https://www.supremecourt.gov/DocketPDF/18/18-801/100234/20190517154739195_18-801%20Peter%20v.%20NantKwest%20Inc.%20Full%20JA.pdf
http://typedia.com/explore/typeface/cooper-black/
0 notes
Photo
Our task for Monday Week 3, to document an interaction.
0 notes
Photo
For Thursday’s class in week 2, we needed to choose a website that we felt was an effective example of well-structured information architecture. I chose Arion, one of AUT’s websites, as I feel the drop down menus are well laid out and easy to follow. It tends to get a bad rap from people within the design department however my experiences with it are always relatively painless. I also think that the way the website is coded allows it to run very fast, making it more desirable to use than some of AUT’s other web portals, like Blackboard and the Student Digital Workspace. It only takes two clicks to get to any given page, and this is including clicking the “Login” button.
However the class was quick to point out that having a “dashboard” functionality on the homepage which displayed things like your timetable, fees and other uni-related info would eliminate the need to click at all. This could be improved even further by allowing users to customise this dashboard, displaying only the most relevant information. The site also isn’t optimised for mobile browsers, with people noting the the elements on the page were slightly too small to be able to accurately tap on a phone screen.
0 notes
Photo


For our first class in week 2, we were tasked with drawing 20 things we had interacted with in the morning on our way to uni. We then had to sort them into categories, with no limits on what the categories could be. Meela and I decided to sort them into locations (bedroom, kitchen, bathroom, leaving the house, transport, and uni) and arranged them right to left according to the chronological order we visited those locations.

Next we joined with another pair of partners and Raul added some limitations on what the groups could be. We needed to sort the objects into three categories that would would represent to an international student what an average morning routine for an AUT student would look like. After some deliberation, we sorted it into things needed at uni, things needed for the journey, and things needed at home.


Finally we were tasked with conceptualising a website/app which could display these items to an international student, and creating menus and submenus to accommodate our categories. The original three categories seemed appropriate so we kept them, although we adjusted “things needed for uni” to “Tertiary Life” and “things you need at home” into “Accommodation”. We felt the need to split “Transport” into public and private. We also split the accommodation to account for the different living situations that international students might encounter.
1 note
·
View note