Glenn Sæstad

Design Student // GK3 Interaction Design // Oslo School of Architecture and Design A messy stream of work, activity and notes, sorted by tags.

[gsaestad]

AHO Works

Our class worked together to make a messy but fun show for the semester exhibition AHO Works. The visitors seemed to enjoy the playful and informal vibe. We even had people from the Natural History Museum come to look at our installations.

Unfortunately, I had to disassemble the internal parts of the installation when I made the project film. This meant that I couldn’t give a live demonstration to the visitors. I had the video on display to make up for this, which showed both the functions and the intended experience of using the installation. 

We also had our app projects on display. Max made a really cool hub website for all of the projects, which we displayed on two computers. We also printed out the websites and used QR codes and tinyurls to link to the prototype apps. That way the visitors could test them out on their own phones.

[gsaestad]

Succulents live in pretty harsh conditions...

...a curious interactive museum installation by Glenn Sæstad.

This installation celebrates the cute but remarkably tough succulents. They have adapted to withstand sour soil, dry heat and hungry animals. Mash the buttons, and watch them fly between the walls of this arcade machine. No matter how big of a beating they get from their environment, they still hold on and survive.

Below is a selection of my sketching process.

Paper prototypes, gifs and iteration have also been instrumental for the project.

Laser cutting parts for the final model from plywood revealed a huge finish/time ratio.

A concise and well planned storyboard made the video process smooth as butter.

The physical model together with the project video successfully conveyed the intended function and experience to the visitors at the AHO Works exhibiton.

[gsaestad]

Bak Byen // Behind the City

“Bak Byen” is an app highlighting the invisible work done by the city workers of Oslo. Every single day they make sure that our city runs smoothly and looks its best.

The app builds on the work logs reported and kept by the city administration. It visualizes the reports through illustrations, maps and long term statistics.

https://xd.adobe.com/embed/919dcd12-f8d9-4e95-99bd-aacecc4c6af5/

Once a day, early in the moring, the app gives you three reports based on your location and interests. We want you to notice the  small things that have been done right outside your very own doorstep.

[gsaestad]

Some rough sketches I collected from the “Bak Byen” app project

[gsaestad]

Victorious Cupid: Week 4 & 5

The last two weeks were all about finalizing the concept, refining the visuals and producing all the final presentation materials.

We decided at the start of the week that the user context should indeed be in the morning, right after waking up. This meant that the app would update the displayed activities once a day, early in the morning. We wanted to avoid the feeling of an endless feed, as well as not having the user constantly feeling the urge to check the app for updates during the day. We also decided to deprioritize the notification aspects of our app since talking to users had revealed that people are generally skeptic to notification interaction. This aslo let ut focus on the much richer experience inside the app.

The illustrations that we made the week before consisted of the work being done and the environment around, but we realized something important was missing: the workers! Where were the human beings we actually wanted people to care about? We completely redid the activity elements of the visualizations, making sure to include and highlight the actual workers in every one.

^The old illustrations for changing light bulbs in Bjørvika and snow shoveling in Frogner. Not a single sign of human presence...

We felt that the new visuals were much more human and realistic, and also made the impression of the actual work much more impactful. Changing the light bulbs at the top of St. Hanshaugen is actually a lot of work because the workers have to move a big lift all the way to the top of the mound!

We also made a larger range of locational illustrations and colored backgrounds. We wanted to focus on the unique look or landmark of the area, like the water house on top og St. Hanshaugen and the barcode architecture of Bjørvika. How specific or general the covered areas are, is something that is still left to experiment with.

We imagined that the colored backgrounds could be based on the time of day or setting, as well as the yearly season. We made this palette of autumn and winter colors as an example of this. All the backgrounds have matching gradients. We chose this look to contrast the simple line weights of the illustrations and give the interface more depth. The specifics of the color choice and the other seasonal palettes are some things that we still need to work out.

A foreground work illustration, a middle ground locational illustration and a colored background are all combined to make the visualization on the first page. We made a simple chart to show how this method workes.

This system let us quickly generate lots of content and examples to discuss.

We separated the report into three parts; the welcome message and illustration, the map, and the statistics. We did this to keep the interface nice and tidy, as well as to separate the report into different “moods”; poetic, specific and holistic.

https://xd.adobe.com/embed/919dcd12-f8d9-4e95-99bd-aacecc4c6af5/

The first screen also consists of a text element. We set up a table to show how this could be automatically generated.

The system looks at the work reports, and matches the correct text clauses to generate the full message. It also takes into account the current time and the user name submitted to the phone’s operating system. One specific text could sound like this: “God morgen, Martin! I går vannet vi skøyteisen i Spikersuppa så nå kan du finne fram skøytene” / “Good morning, Martin! Yesterday we watered the skating ice in Spikersuppa, so you can now get out your ice skates.”

The map part of the app will be generated using an existing map service customized to fit our visual style. We tried to simplify and stylize the map, while still keeping it recognizable. The work logs contain pretty acurate location data, and we want to highlight this to the user.

The bottom part of the screen contains more data from the logged reports. The thought was to give the user a glimpse of the bigger picture, both in administration, activity and time.

Below is an example of a full activity report presented to the user.

We decided that the user should get three of these reports a day. This was chosen because it lets the user see a variety of content within the first couple days, without it feeling like a big feed. We also decided that the daily reports would vanish forever at the end of the day. This also reduces the feel of a feed or an archive. 

While working on refining the app, we simultaneously worked on making the video to present our app. We discussed a couple ideas and directions we could go, before we made some storyboards to compare them.

^Notes from our first round of discussing video concepts, along with comments from Hans Gerhard, one of our teachers. (Note: collaborating on drawing a penis is a very effective team building exercise)

We used a post-it note for each frame of the storyboards. This let ut quickly iterate and compare new ideas while we discussed afterwards.

We wanted to portray an aspect of wonder and excitement in our video. The concept we ended up with has a person waking up, checking their phone and then inspecting  some of the work that has been done. This illustrates the intended effect of our porject: to make people notice their surroundings.

This was the video we showed at our final presentation. Even though we were more or less happy with the edit, the video could still use some more text and better screen animation. Luckily, it was just a quick fix to do before the online delivery of the project!

[gsaestad]

Victorious Cupid: Week 3

Between week 2 and 3 we realized that a lot of our research and design arguments were based on guesswork and assumptions. We had looked at the city administrations website and tried to map it out, but we didn’t document it or gather it all together. This made it very hard for us to discuss ideas and viability both between ourselves and externally. We had spent a lot of time discussing but made very little actual design work. This week we really wanted to gather real documentation, make some stuff and get things going!

We started the week by collecting screenshots of the different posibilities within actual notification frameworks of iOS and Android. Both operating systems have recently added “rich notification” frameworks, which opens up a lot of possibilities for user interaction before even opening the app. It was important for us to get a clear view of how they worked, so that we could make viable and realistic design proposals.

Although the visual look of the notifications are different on the two platforms, they contain roughly the same elements: collapsed and expanded views, designated text and graphic areas and direct actions.

A big different between the Android and iOS however, is that the unopened notifications are persistent on the former platform, but disappear from the lock screen on the latter. If we would decide to continue exploring notification interaction, then we had to keep this mind.

We made five different prototypes to test out different levels of interactivity and complexity. We wanted to find out what real users actually found interesting; simple information, personalization, feedback or visualizations. All prototypes started with the same lock screen notification so that we could focus on the in-app experience. 

The first prototype tried to channel the minimalistic spirit of the earlier concepts. It gives the user a simple message of a recent activity by the city with the possibility for the user to read more messages.

Prototype 2 included the possibility for the user to get messages related to their own areas of interest. This personalization would also be reflected in the following lock screen notifications. Another difference of this prototype is that it has two levels of information. The first level is a short notice of what the city has done. The second level, which the user may or may not open, gives more in depth information about the details and context surrounding the activity.

We also wanted to test out the possibilities for simple feedback from the user. How would the users feel if they could quickly let the city administration know how they felt about the work being done? We used the emoji based reactions from Facebook for two reasons; firstly to give them a larger range of expression than like/unlike, good/bad etc, secondly to test out how they felt about this informal way of interacting with the city administration.

To expand further on the concept of feedback, we made a fourth prototype which included the option of adding a text based comment to the emoji based reaction. We hypothesized that this would be especially relevant incase some of the users felt the need to respond with anger. Would this be because they didn’t agree with some of the work the city did, or maybe they way it was being done? We wanted to ask the users if they could imagine a scenario where they might react negatively in our app.

The last prototype focused on presenting the information much more visually by marking the completed work precisely on a lifelike three dimensional map. This prototype was the least fleshed out, with just a simple screen with no interactivity beyond the notification screen. This actually worked quite well as an exploratory tool for discussion because we could ask the testers what they thought the app would do next or what they wanted it to do next.

We spent the afternoon testing out our prototypes with both other students at AHO and strangers on the street. Each user got to test all prototypes in the same order. That way we could compare how the users reacted to the different iterations.

We learned a lot from doing this. We quickly realized that communicating the information purely through text didn’t really captivate our users. We hypothesized that a simple text based message would lead to a mindfull and poetic experience, but it seemed that our users simply didn’t registers the actual information on the screen. Out message got lost among the daily information overload! We also saw that having lots of different messages available for the users led them to endlessly scroll through the “feed” of activities, again without registering the actual content. This meant that we would have to limit the amount of content in future prototypes. Overall though, it seemed like our users didn’t really love our concept. Relating back to the context/motivation/content-framework, the motivation part was certainly our projects weakest link. A glimmer of hope emerged when our users got to the fifth and final prototype. When they saw the activity placed on a map, the information suddenly got much more relevant for them. “Oh, now I can actually go for an evening walk there!” a user exclaimed after seeing where the city had fixed the broken street lights along the Aker river. We then knew that working on the visual aspects was the way to go forward.

We also did more concrete research on how the city administration operates. We called a service worker at the department of city planning, contruction and property to ask about the work logs for the work the city does.

This chart shows how the information flows between the citizen, the city administration and the contracted entrepeneurs when a cititzen submits a request for city maintenance. If the citizen has categorized and location marked their request correctly, then the information goes automaticly to the correct entrepeneur contracted to that specific activity and location. After the work has been done, a report gets sent back to the city administration containing information about the time of day, work hours, location and component use. This information gets archived somewhere automaticly as well. The city administration’s part of this flow is mostly automated. This means that it would be possible for our app to be run fully automated by simply tapping into the exicting reporting system.

We also needed to prove that the actually was enough work beeing done in each neighborhood for our concept to utilize. We made charts documenting all the possible activities our app could display to the users. We sorted the activities into frequency, season and type of work like routines, uppgrades and repairs, along with mapping them out in a typical Oslo neighborhood.

After reviewing all our insights from research and user testing, we made two last prototypes for the week; one personal map based and one visual illustration based.

https://xd.adobe.com/embed/0ff2cd1b-e0c6-4e65-8605-6e279d3edd8d/screen/de4ceeec-b121-4c7d-aaeb-f641501d5340/iPhone-6-7-8-20

The personal map based prototype shows the user a selection of activies based on their interests and location data. The information is presented in two levels; a short overview and a second detailed paragraph. When the user closes the message box, a map with the active area highlighted appears. We chose to separate the text and the map into two different layers after seeing the users getting confused and missing information when they tested the map based prototype 5.

The concept uses an automatic algorith to make the selection of activities more relevant to user.

The algorithm looks at previous usage patterns and location data. It compares both the activity being done, the location of the activity and the location of the user, and relates it to how the user has responded to these parameters before. The algorithm still has a degree of randomness, as to not get put in an endless loop of the same types of activities in the same locations. A nice metaphor for this system is a lottery bowl, where the algorithm adds more tickets for the activities most relevant to the user.

The second prototype utilizes poetic visualizations based on the data included in the work report from the entrepeneur. The illustrations consist of a forground showing the work, a middle ground showing the location, and a colored background based on the season and time of day. These elements are stored individually in a resource bank which the system pulls from. The bank contains pre-made elements matching all the different activities, locations and points of time. The text elements are also generated form a given set of clauses. The user can chose to scroll down to a second screen which is more statistics focused. This screen contains a stylized autogenerated map along with the raw data from the report. 

This flow chart shows the visualization generation process. All the elements of the screens are pre-made and automaticly generated based on the activity logs from the city administration. This allows our app to be completely self run after the initial set up.

We saw potential in both of these concepts, and hoped to combine elements from both is the following week

[gsaestad]

Comparing notifications on Android and iOS

[gsaestad]

Researching notifications on Android

[gsaestad]

Researching notifications on iOS

[gsaestad]

[gsaestad]

Victorious Cupid: Week 2

The presentation website for week 1 of our brief: explore how mobile applications might enhance and expand how citizens interact and related to the city of Oslo.

We started week 2 by mapping out possible context scenarios involving different activities, motivations and content. After reviewing the concepts from the week before, we concluded that there was a potential for exploring the relationship between aesthetic/poetic value and usefulness for the experience: The app coul either be a function oriented tool, a poetic experience or something inbetween. This led us to graphing out the activities, motivations and content according to their perceived usefulness and aesthetic value. The activity “getting ready to go outside” for instance, would involve more usefulness than aesthetic value, while “waking up in bed” could involve both aspects.

We imagined that the most relevant context scenarioes involved the users morning routine, somewhere between waking up and getting out the door. The user motivation could be to plan their day or getting a better understanding of their own surroundings. We found lots of different datasets to work with, but chose to focus on locational data, work logs and city planning history.

We imagined four potential user personas and sketched out their hypothetical usage patterns, morning routines, travel patterns etc. We then visualized their traits using radar charts to better be able to compare the different users. The traits we chose were interest in city geography, technology, functionality, aesthetics and city planning. We chose radar graphs because no traits were at odds with each other; one user could be highly interested in functionality and aesthetics or not.

Ida then conducted interviews with people we thought matched out user personas. We wanted to get a better understanding of the morning routines of these users, their phone usage and what they knew about the cities activities near them. A big discovery was that they all had a pretty negative relationship to notifications. They felt that they were constantly bombarded with unwanted and interrupting notifications about stuff they weren’t really interested in. We had up until this point, focused a lot on the notification aspect our concepts. so this insights made us reconsider the appropriate use of a notification based system.

We had discussed different ideas and concepts based around the same general pattern; some sort of notification interaction, a visual representation of the information and letting the user explore the data further.

Hannah made a rough overview of all the elements and their possible flows, which then let us ideate further within different sections.

The minimalistic approach tries to keep as much of the app interction within the phone’s lock screen notification. The thought is to give the user just the essential information and take as little of their time and attention as possible. When the user has dismissed the notification, the information is gone forever and the app will not interrupt the user until the next morning.

We explored the posibilities of using a map to make the user better relate to the information. This concepts considers the users home location and highlights the closest and most recent work done by the city. As the completed work gets older, the highlights fade, which gives the map an aspect of time. It is also possible for the user to explore the map if he or she wishes, by zooming out and dragging the around the map. 

The map could also focus on the long term work being done to develop the city. This variation highlights city planning activities and how they manifest in the streets around the user. Small activies, like removing a parking spot, is often a part of a bigger city plan initiative. The app also lets the user explore these related and overarching plans. This lets the user se the bigger picture, and shifts the view from the localized street oriented view of the former variation.

We also tried to integrate our ideas into the city’s existing services. This concept utilises the same map and work logs as before, but lets the user report problems and request work to be done in the streets around them. We also imagined the possibility for the user to subscribe to updates about their submissions. These services already exist within the city administratons, so this concept would be more of a redesigned offering, than something completely new.

The last concept was something we explored as an effort to broaden our vision and not settle for our first ideas. We ended up discarding this concept, but it helped our confidence in our original plans. At the end of the week we decided to simplify and distill our concept to something between the minimalistic approach and the “work in the street” focused map. The thought was to make something simple but well executed and polished in stead of something complicated but rough.

[gsaestad]

Polite Littering:

The act of neatly placing your trash in stead of throwing it on the ground.

I noticed that people all over the city are placing their empty cups and food packaging on ad-hoc shelves. Do they think that this somehow isn't littering? Who is supposed to pick it up? This website is a part of the Introduction to Interaction Design course at the Oslo School of Architecture and Design, Fall 2017. The brief was to explore the city, document a curious discovery and share it through a website.

The design of the website is a result of experimenting with different CSS  properties, and trying to relate it back to the content. I wanted to show of all the different varieties of polite littering that I had found along with my own thoughts and remarks, so a grid based gallery made a lot of sense to me. This let me create a shuffled stream of pictures and comments with less hierarchy and more “flow”. 

At this point, the website was pretty static, and felt more like a printed poster than a website. After trying out different interactive elements, like hover and scroll effects, I settled on a horisontal expanding and collapsing hover effect for the whole gallery. The gallery starts off collapsed and cropping out a lot of the context around the litter. I wanted the cropped view to peak the visitors curiosity, and make them “look inside” by hovering over the gallery. I also placed the title, explanation and hover instruction on a static sidebar, to separate it from the main content, and to further feel of a “proper” interactive website.

I kept the styling of the website fairly neutral to focus on the content. I wanted the website to make people think twice before politely littering again, but without beeing overly judgemental or dramatic. There is still some refining left to do, like working with how the text overflows in the collapsed view and the images scale, but I’m pretty satisfied with this beeing my first “real” website.

[gsaestad]

Victorious Cupid: Week 1

The presentation website for week 1 of our brief: explore how mobile applications might enhance and expand how citizens interact and related to the city of Oslo.

We started the week doing two big mapping sessions: first we mapped out areas of interest within all the branches of the city administration, then we focused on areas within our chosen branch; “Planning, construction and property”. We chose to work within that field because we felt it was somewhat “unsexy”, and gave us a oppurtunity to make it more delightful, playful or exciting.

We mapped out both areas, challenges, oppurtunities and ideas relating to the department. We realized that there were a lot of activities and information within the it: Maps containing endless amounts of information, lots of submission forms for the citizens and huge archives of city planning history. This made us see the potential for doing something involving simplifying and visualizing this messy situation.

We gave ourself the challenge of “exploring how the city can communicate its own activities to its inhabitants. How are we affected when we see the invisible work beeing done?” This would hopefully make the people of Oslo more aware and grateful for how the complex machinery of the city runs.

^The city’s own datamap, containing several layers of information; planning history, pollution and noise levels, potential for solar panel installations, area usage and much, much more.

We then brainstormed lots of different ideas for our brief, which we then condensed down to three potential concepts.

Concept 1: Mini-Oslo

A miniature, interactive city in your pocket. The activities in the app reflects what’s actually happening and being done in the real world. The interactive experience could have some sort of communication between the city administration and its citizen, either one or two way. It could be a part of some sort of PSA or campaign, or be a stand alone “delightful” experience

Concept 2: The voice of the city

An app giving you information about what the city is doing in your immediate area while you are traveling. This could be current activities, statistics or long term information. The app will give this information as small snippets or “drips”, either through audio, text or visually.

Concept 3: What happened tonight

A notification based app, giving you a daily report of what the city’s workers did while you were asleep, like sweeping the streets, salting icy roads or picking up garbage. The format is inspired by the morning paper; something you read in the morning “while its fresh”, and then think about the rest of the day,

Even though concept 2 and 3 were a little similar, we felt that they focused on different contexts and experiences: concept 1 involved the users morning routine inside their home, while concept 2 involved the user while on they were already interacting with the city. We also thought that both concepts had a more direct connection to the real city than concept 1

 We ended up chosing to work further with concept 3, “What happened tonight”, because we felt the morning context was more intimate and poetic, and also gave us a set frame and user context. We still had the ideas of concept 1 and 2 in the back of our heads though, just in case we realized they could add something valuable to our main concept.

[gsaestad]

[Victorious Cupid: ]

Communal activities in the city of Oslo. Making the invisible visible.

Ongoing group project with @hannanorth, @idalahm and @legolai.

[gsaestad]

[Polite littering:]

The act of placing your trash neatly in stead of throwing it on the ground.

[ahointeractiveproducts2017]

The Web and the City

Over the last decade, digital technology has become another layer in the already dense and complex context of the city, and urban life has become an important new site for interaction design. The city has become interwoven with networked technologies, and ever more sophisticated mobile phones are shaping how we understand and experience our urban environments.

Task

Over the next weeks, you will be working on a creative task where you are going to be introduced to the basic tools and methods for designing for and with screens and the web.

For this project, you have been approached by Oslo Kommune to explore how mobile applications might enhance and expand how citizens interact and related to the city. They want you to design and communicate a small scale application for mobile phones. Small scale means your application doesn’t have to end poverty or fix city government. It should be rather small and humble, yet interesting or useful, playful or effective. It doesn’t have to be for everyone, it can have a small and very specific user group. It doesn’t have to be designed for eternal relevance, it can be valid for only a specific period of time.

The application should focus on one core function, and it should do that one thing really well.

They point the following, non-exclusive,  points as possible areas for explorations:

Information dissemination. How may we improve how we distribute information in order to make it more understandable and accessible?

Engagement. How may we make citizens more engaged and involved in city development?

Service offerings. How may we improve our service offerings? How can they be more understandable, approachable and engaging?

Playfulness. How can we make the urban environment more playful, inclusive and make people take part in new and delightful ways?

Feedback. Can we improve how we collect data from citizens and environments?

Awareness. Are there ways we can make hidden aspects of the city more available so that citizens might become more aware of their surroundings?

Provocation. How can we bring attention to undiscussed topics?

You may choose from the following branches of city administration as your starting point:

Helse og omsorg

Natur, kultur og fritid

Plan, bygg og eiendom

Gate, transport og parkering

Miljø og klima

Folkehelse

Trygg by

Vann og avløp

Process

Choose a thematic area quickly. Then start to research that area. What is the city doing, what is it about, what are interesting areas for exploration? Talk to people about their experiences within your area.

You need to start investigating ideas for your project and develop a basic concept that will be refined through the process.  Methods such as observing people and situations, in-context sketching and ideation workshops are useful here. You need to quickly decide on concepts and move on to thinking about and defining users, use situations, user flows and further to sketching and prototyping both by hand / paper and digitally. Iterate. Iterate!

We want to see bunches of sketches, variations, and testing. The emphasis of this module is design through making and we expect a hands-on approach to all aspects of your process. Overall we expect you to progress from ideas, through research, concept, and prototyping quickly and to iterate.  We hope to see you working efficiently and evidence and prototype early so that you get the chance to evaluate and re-design.

Deliverables

You will present your product / service / app in the form of a website. This should convey how the application works and what is great about it. Why is the app useful, fun, delightful or interesting? The site needs to contain one or more films that present and communicate your app. The website and film(s) should highlight the core functionality and concept of the app and why others should care and eventually buy or download your app. So, you have to make three things, an app,  video(s) and a website. That means you will have to think about these things interconnected and related to each other. To repeat, the deliverables are:

An experience prototype of an app. This means that you have to design interactions that can be experienced, not necessarily work technically.  You do not have to make a functional app or make a technically sophisticated prototype, most importantly it must clearly and convincingly convey how it may be used and experienced. There are several prototyping tools available for this.

One or more short (max 60 sec) films that present the app’s functionality and use. Think about what you learned from the filmmaking brief and apply this to the app. The video(s) should both present and explain the core functionality of the application in an engaging and delightful way. You should also keep the video in mind when you design and prototype the app itself. What are the interactions that you want to show in the video, and how do you communicate these well? Please: no intricate stories or acting and no music (use contextual sound). Focus on communicating what the application does and why that’s interesting / useful / fun.

Make a functional single page website that presents the app and service. The site is your final presentation.

You should plan your process early and delegate tasks within the team. Try to map out all that needs to be done, and figure out how long you have on each part of the project. Part of the challenge of this project is to put together the skills and approaches you have worked on so far in the semester and run a design process using these.

[gsaestad]

The Web and the City / Thematic mapping session

Politely stolen from @legolai