samanthagard-mddn352-blog

[samanthagard-mddn352-blog]

Project 3 - Reflection

Overall I’ve really enjoyed this paper and especially this last project in seeing my idea and app really come to life. I’ve learnt a lot about Firebase and storing data which I think will come in handy with any future projects I decide to take on. 

Group projects always have pros and cons, and I knew this going into the project. I considered working alone to finish my app, and perhaps I would have been more happy had I done this. But I think working with James and Fintan definitely improved the app beyond what I could have done, as there were multiple opinions and inputs, and ideas bounced. When I work alone, as soon as I get an idea I go with it, not really considering other options. 

James was great to work with, he has a knack for designing simple and aesthetic user interfaces and experiences. The interface for WeatherFlex (formerly Foresee) is great. I really love how we’ve made it simple, colourful, and playful while also being easy-to-use, accessible, and highly functional. 

Fintan is great too - he definitely exceeded my expectations after not getting much out of him in the first couple of weeks. It’s always hard working on a project when you don’t understand/are not familiar with the base code. Perhaps this is something I should have sat him down with and explained it all before he started working on it. It was definitely hard for me to delegate functionality tasks to him when I had a very specific idea of how they should be done or approached. But he pulled through and created some awesome features.

All in all, fun project, I’m happy with the outcome, and think I might continue working on it even once I’ve handed it in, just to clean it up and have as a fun example piece of work. 

[samanthagard-mddn352-blog]

Project 3 - Last Changes and Fixes

Added meta tags  and link icons for saving and opening the web app as a ‘native’ app for iOS, such as hiding the safari header/nav bar and opening it in fullscreen with a splash screen + icon to save to the home screen

Copied across + edited Fintan’s code for the forecast data. I’m not particularly happy with how this turned out to be honest. While it works, it doesn’t really tell the user that much about the forecast for that particular element. Each component displays a very similar bar graph with no data telling them what the bar means or even a label. The infrastructure is there, but how it’s displayed is really not that user-friendly. I think this is due to the time constraint - Fintan didn’t really start working on the app until about a week ago and we didn’t have enough time to get James to come up with some approaches to how we would visualise the forecast data for each component. However, since Fintan had done some work I decided it was best to copy it across to show what we did have. It’s pretty messy - a mixture of Fintan’s jQuery + my Javascript hacks to get it to work with the database and current API calls etc. 

Added James’ “About” information in the settings screen . Which reminds me - I’m also a little unhappy we didn’t have time to get the settings working. The settings I’d wanted to get working were switching between metric and imperial units, and allowing users to set up push notifications based on forecast weather data. This was one of Fintan’s jobs, but again due to the time constraint we weren’t able to complete this.

Fintan’s original code for the forecast graphs included labels for the current data and for the next four hours. These labels were as follows: ‘Current’, ‘Hour 1’, Hour 2’, Hour 23, Hour 4’. This was also not very user-friendly, so I decided to write a quick function that would take the current time and display it alongside the current bar in the bar graph, and then calculate the times for the next four hours and render those against their related bars.

[samanthagard-mddn352-blog]

Project 3 - Editor Screen and Last Fixes

I had been ignoring the fact I still needed to create functions for rendering pressure and humidity data so quickly whipped this out yesterday. I created all the icons needed for these as well. I also redid the way cloud cover was represented, as before it was done with a canvas ‘pie graph’, but it wasn’t obvious that it was meant to be cloud cover in any way. So I created a cloud outline and a cloud fill, and I just mask part of the cloud fill depending on the percentage value returned from DarkSky. For humidity it just renders the percentage value inside the icon I created, and for pressure it does the same, but also rotates the pressure-pointer icon, which simulates a pressure gauge, depending on the value returned. 

I then created the functionality for how the editor saves the user’s chosen component variables. When a user is created, it saves the default variables (temp, rain, wind, cloud) and renders these. However, if a user wishes to change these, all they have to do is go and select the new variables in the editor, and these will be rendered instead. This took a lot of fiddling around with all the functions, as I had to change how each renderTemp() etc. function worked, but after a couple of hours I had it sorted. 

There are still a couple of bugs I need to iron out, as well as pulling across Fintan’s forecast graph changes. James has been working on our presentation content for tomorrow which is great to not have to worry about that. We are all meeting this afternoon to sort out these last few things.

[samanthagard-mddn352-blog]

Project 3 - Getting There

What I have achieved since my last blog post:

Added new theme options designed by James

Removed all old 4C Logos, and replaced with the new WeatherFlex one designed by James (precomposed touch-icons for saving the app to your phone home screen etc.)

Added a ‘current location’ button to the Locations screen so users can return to their current weather data (calls the getWeatherData function using the latLng it gets from the users current position)

Fixed the issue with how the main container info was displaying as it was initially hard-coded to fit an iPhone 5 screen size

Created a function to clear user data from the screens on sign out, as if you signed out then signed back in, the app would render everything twice (as locations etc. render on sign in)

Met with Fintan to pull across his work on resizing the modules so that we could start working from the same branch. He still hadn’t quite finalised it, and we looked into a few different options, but we managed to get the resize functionality using jQuery’s UI ‘resizable’. Fintan had this working, but it works on a drag event, which we already had for moving the modules around. So I looked back at the Draggabilly library, and found that you could set a handle element, that only allows the modules to be dragged if the user is dragging on that specific element. This worked perfectly, as the resizable library also has a handle. I cleaned up a bunch of his scripts, tweaking them to make sure all bugs were removed. I’m still not super happy with having two different things happen on a drag even on the same element, it doesn’t seem very user-friendly. I really wanted the click event to cause the modules to expand, so I might take a further look at what I can do there, if we have time. 

I’d been waiting on James to give me designs for the editor screen, and had been thinking about how we’d let users select the elements they want displayed on their home screen. I wasn’t sure how best to visualise a selection, but lo and behold, I’ve decided to do selection boxes.... This will make it very easy for me when it comes to scripting the functionality for rendering each component based on the users’ preferences. 

[samanthagard-mddn352-blog]

Project 3 - Update

Since my last post, I’ve mostly been working on more Firebase/locations stuff. I was having issues with how to retrieve data from Firebase, but it’s actually quite straightforward. You just need the database reference - e.g. firebase.database().ref('users/' + user.uid), which gets me to the user ID node, nested inside the users node in my overall database. As I don’t need to be actively listening for data changes, I can then call the once() method on the db reference and retrieve a snapshot of the data stored there. All my functionality flows from there. 

After lots of trial and error, I have finally got the addition and removal of locations to the Location screen working! Users can ‘search’ (more just enter) a place name, and then add it to their locations screen. If the API call comes back with a location result, a location element is added to the list, and a listener is set up on this element, so that if touched, it will load up the home screen with that location’s weather data through storing the lat/lng variables. 

Users can then click the ‘edit’ button on this screen if they wish to remove any locations, and then click the delete buttons next to whichever locations they no longer want. 

Once this was finalised, I was able to use the same idea to save the ‘theme class’ which is used to control what colours are used to style the app. This is done by changing a class on the body, and using Sass variables and mixins to control what changes. It was definitely easier, as only one value needed to be saved - a string such as ‘theme-default’ or ‘theme-dark’. Here are some examples of the themes we have come up with so far:

I have also delegated a number of tasks to James and Fintan.

James:

create add and remove locations icons to replace the '+' and 'x' i've used as placeholders in the locations screen

create content for the 'about' section in the settings screen, and designs for how that's going to be displayed

update the themes screen to show the current theme (default) is being selected? (currently there's no obvious way of telling)

come up with maybe 5-10 finalised theme colour combos

finalise the logo - and the image we are going to use for the icon/saving the app to home screen etc

refresh and current locations icons need to be incorporated somewhere in the home screen

continue working on the presentation slides

Fintan:

start experimenting with d3.js to create graphs from the forecast data

continue working on the animations for tapping the modular grid icons

make another attempt at push notifications once these have been completed

Fintan and I will need to merge our branches soon to make sure we don’t have any conflicts. I’m a bit worried... but we will see what happens. If it all craps out, I’m sure we’ll just be able to copy his code over into mine manually.

[samanthagard-mddn352-blog]

Project 3 - New UI Implementation

Over the last few days, James (along with some input from me) has been working on creating new designs for the UI and screens of the mobile app. We have been using Figma, which is a great online tool for collaborative screen designs:

We finally settled on a bunch of layouts and components we liked, including the addition of a icon bar along the bottom of the app, as opposed to the hamburger menu and dropdown menu I had in my prototype. The icon bar includes the 5 top places we believe users will visit in regards to accessing the weather and customisation purposed of the app (Settings, Themes, Current Location Weather, Saved Locations, and the Homescreen Editor). We also designed the screens for these.

After we had finalised these and received some input and feedback from Fintan, I began to strip out the relevant parts of my old code and update it to fit the new designs. This was quite a tedious process, as I basically had to redo the stylesheets (now using Sass which is incredibly easier, should have used it in the first place). But our current app is looking very slick now: 

-

-

-

-

-

-

The authentication screen works really well, and I have tested this with multiple people - everyone has been able to sign up with an email and password, and then log in without any problems. Next steps I think will be to get the Locations functionality and screen sorted. This will lead on well to the Themes and Editor functionality as they are very similar. James is currently working on designing further icons, animations, and desktop screens. Fintan is working on the visualisation of forecast data, hopefully with d3.js. His work on push notifications is part way there, and he has some of the basic functionality down, but we decided as a team it was less important than the forecast data.

[samanthagard-mddn352-blog]

Project 3 - User Auth and Storing Data

I have set up Firebase Authentication, where users can sign up and/or log in with an email and password. This sets up a user account in my Firebase console with a corresponding unique ID, primary email address, name and photo URL. I think only the user ID will be relevant to me, aside from the email for the initial sign up and following sign ins.

I was really struggling to figure out how I would store and assign data to specific users, such as the locations they wish to save, and colour, layout and settings preferences. After looking into it, it seems that Firebase Users and the Firebase App Database aren’t actually linked. However, I believe that I can save data in the App Database under a Users node, and then create a separate User node for each user, saved as their unique user ID. This will be easy to do, and all I will need to do to retrieve that data is obtain the user ID once they have logged in, and then fetch the corresponding data from the App Database stored under that ID.

I have tested that this works in my login test page, by logging in my user account, and then setting a name variable under my unique ID in the Users node of the App Database. Before I begin to full implement this, I need to make a list of what variables will actually need to be stored, and then what functionality surrounds how they will be stored.

[samanthagard-mddn352-blog]

Reading Assignment

Skeuomorphism is a design concept which involves creating elements that represent their real-world counterparts. In the realm of UI and web design, this means creating three-dimensional effects on a two-dimensional surface. For example, in Apple’s Garageband application, functional aspects of the user interface have been designed to replicate controls such as switches, knobs, sliders and buttons from the original physical devices they were designed for. In recent years, Apple and Microsoft have taken different directions in this topic - Apple has followed an approach using faux textures, drop shadows and visual metaphors, while Microsoft has embraced the rise of flat design by using minimalism and colour in their user interface design.

The advantages of skeuomorphism are plenty - there are constantly new interactive technologies, and having recognisable interactive elements allows a smoother transition into a phase of increasing technological consumption. The concept also helps to make an interface feel more intuitive to first-time users, without them having to try and figure out what certain elements are representing. However, problems can occur when the limitations of the original design are brought in - even when there is no reason for those limitations to exist anymore. Flat design appeared out of the opposition to skeuomorphism, and is almost the complete opposite. It can be very visually stunning, but there is level of sterility that can prevent it from being warm and welcoming to users.

A lot of designers believe that it shouldn’t be a choice between one or the other, but rather that both should be used as design tools. The recent release of Google’s new mobile apps appear to be in the style of ‘skeuominimalism’, which takes the best components of both approaches - where simplicity doesn’t affect the usability, but skeuomorphic components are still used without affecting the simple aesthetic of minimalism.

Reference

Page, T. (2014). Skeuomorphism or flat design: Future directions in mobile device User Interface (UI) design education. International Journal of Mobile Learning and Organisation, 8(2), 130-142. http://dx.doi.org/10.1504/IJMLO.2014.062350

[samanthagard-mddn352-blog]

Project 3 - Planning and First Steps

For Project 3 I will be working with Fintan Nelson and James Erwin. Fintan’s Project 2 has some functionality that we can integrate into my app, and James is an expert (in my eyes) in UI, colour, typography and the like, so I believe he will be valuable in improving and updating what I already have in this realm.

Today I started breaking down what we need to do to get Foresee to a point where it can be used properly, and marketed to the public. First I set up the Github Repo, and then a Trello board for us to keep track of what each of our roles and tasks are. I also set up a Surge domain for the site for testing. 

From there, I started breaking up the tasks for Trello. Here is what we currently have:

To Do - UI

Update and improve current UI components

Conceive 4-5 colour schemes to be used as themes (decide on a default theme)

Incorporate refresh icon into main home screen

Desktop layout designs

To Do - Functionality

Push notifications based on parameterised weather options

Resizing grid modules (discuss the personalised/grid module/how we want users to be able to customise)

Tapping on grid module should reveal weather forecast data for the next 6/12/24 hours

Selecting 4 components to be displayed from overall 6 (Will need ability to save preferences as well, tied in with User Auth)

Saving locations in the side menu (User's current location calls API with lat/lng coordinatesWith saving a location, we have two options: Call API with city name (not always guaranteed to work/spelling errors) OR run a reverse geocode on city name (maybe use address autocomplete/cleaning to get accurate place name) and then get lat/lng coordinates from place name then plug into API_

Firebase User Authentication (found some links to help me get started: https://www.youtube.com/watch?v=-OKrloDzGpU,  https://github.com/firebase/quickstart-js/tree/master/auth, https://firebase.google.com/docs/auth/web/start, https://github.com/firebase/firebaseui-web#installation)

I added Fintan and James as collaborators in the Github repo I set up, so we can start working on our various parts. I also explained to them about utilising ‘feature branches’ to work on separate parts of the design and functionality. This will help with avoiding merge conflicts and testing when we are all working on the same repository.

I then made a start on getting Firebase Authentication working. I managed to set up a separate login.html file that was set up with Firebase, and its Auth system. I managed to create an account with my email and password and sign in/out and change my password through implementing their default FirebaseUI login page. However I need to do some further digging to figure out how I can use this to save certain settings/preferences. I’ve got Fintan working on push notifications based on the user selecting parameters of a certain weather component they are interested in knowing about when it changes. James is going to look at the overall design of the app, and come back with a design document with suggestions and improvements of the logo, UI, typography and then work on the desktop layout designs.

[samanthagard-mddn352-blog]

Project 2 - Final Hand In

Functionality of the prototype:

gets user’s current location

makes API calls to OpenWeatherMap and Dark Sky

returns JSON objects with current and forecast weather data

wind direction variable (degrees) rotates wind direction icon

cloud cover variable (percentage) used to draw canvas arc (pie graph)

other variables displayed as figures in grid modules

draggable modular grid sections

settings and edit home screen menus

error handling if location cannot be found

Functionality to be added should it be selected for Project 3:

tapping on grid module will reveal forecast data for the next 6/12/24 hours

users will be able to order their top 4 components using the edit home screen menu, where the topmost component will be rendered in the primary grid module, and the three others in the secondary modules

the ability to resize grid modules would greatly increase the personal feel of the app, if it’s achievable it’s definitely something I would love the app to have

users will be able to save a number of locations in the side menu - e.g. work/home/holiday destination and access these as well as their current location

Firebase user authentication - includes Google/Facebook sign in capability

Cookie- and/or token-based authentication, setting a session or header to recognise users

authentication is needed as it defeats the purpose of Foresee if users cannot save their preferences/modular grid layout

push notifications are something I would like to further explore - opportunity for scheduling weather updates regarding rain/cloud etc.

Extra notes:

Chrome is the best browser to view (and mark) this web application. I designed it across my ‘device view’ on Chrome Desktop and in Chrome on my Android phone. On some browsers (Safari and Firefox), the behaviour/rendering of the grid is different, which I will look into should it get to Project 3. I believe this is based on something called ‘sub-pixel rendering’ where percentages of pixels are calculated differently cross-browser.

Foresee includes a web app manifest - a simple JSON file that lets the website appear as an app if saved to the user’s home screen. When Foresee is launched from a device’s home screen, it has a unique icon and name (as if it were an app), displays a splash screen while resources are downloaded, and removes the chrome search bar header to allow the app more screen space.

Github Repository: https://github.com/gardsa/MDDN352-Project2

Working Prototype: https://foresee-app.surge.sh

Pop-up message displayed if GPS services are off, or location cannot be found.

Home screen populated with local weather data

Side Menu

Settings view

Edit home screen options

[samanthagard-mddn352-blog]

Project 2 - Days Two and Three

After looking into the data received from both the OpenWeatherMap and Dark Sky APIs, I’ve decided to actually use Dark Sky for the majority of the weather information, but still pull from OpenWeatherMap for some components. Dark Sky provides detailed current weather information for a location, as well as hourly and daily forecast data. My issue with where I pull my data from lies in accuracy. While Dark Sky and OpenWeatherMap have so many different types of data available, when I compare the data I’m receiving from them to what’s actually going on outside my window, it doesn’t always match up. I am still considering using BloomSky, but I think for the ease of this prototype I will stick with what I’ve got.

Then I began to start working on rendering precipitation info. Dark Sky provides a precipitation type, as well as it’s intensity, so not only am I able to show if it’s raining, but when it’s snowing or sleeting.

Then I moved on to working on the two menus. The main menu is a ‘slide out’ menu, which houses the location options as well as a link to the settings page. I  wanted this menu to slide out, but also to push the main content over. I also set up a partially transparent black mask over the main content to redirect the user view onto the menu. I also added an attribution to both Dark Sky and OpenWeatherMap in this menu, as Dark Sky’s terms and conditions ask that this is displayed.

The ‘drop down’ settings menu includes all the options for editing the home screen, such as which components to include and allowing users to (eventually) pick a colour scheme.

My next steps will be to set up the 'settings’ and ‘edit home screen’ partials/pages (haven’t decided whether to create separate html pages, or just have them appear over top of the content).

I also need to iron out some bugs regarding how the modular grid displays in different browsers. In Chrome it works perfectly, but due to something I’ve discovered called ‘sub-pixel rendering’, it appears strangely in Safari and Firefox. This is not ideal as I want all users of different browsers to have the same experience of Foresee. I may need to change how I calculate the size of the grid elements.

Here are some updated screenshots of the home screen and menu views:

[samanthagard-mddn352-blog]

Project 2 - Day One

I’m pretty happy with what I’ve managed to achieve today. I probably spent 5-6 hours actually working on the app. 

I started off by setting up the initial header with the logo, and menu icons. From there, I set about obtaining the user’s current location, and using the lat/lng coordinates to send off to OpenWeatherMap, which has a variety of different  API’s for obtaining current, past, and future weather information. I used both the current weather data and 16 day/daily forecast APIs. 

After figuring out the information I could receive from the JSON response, I decided to set up my modular grid of weather components. I was able to basically pull across the code from my Project 1 example, which I am very glad I did at the time! Not much work required to get that part ready to go.

I then set up the rendering of the location and succinct weather description returned from OpenWeatherMap. From there, I was able to get the current temperature as well as the forecasted low and high temperatures for the day. This was where I realised I’d have to make several different GET requests, as not all the information I want is contained in a singular API call. 

Then I hit an issue. I had to have a secure (https) domain for the geolocation API to work, but the API calls from OpenWeatherMap weren’t secure (this requires paying $500 a month for one of their premium plans). So I tried getting the location information from an IP API, but this returned super inaccurate lat/lng values so that was a no-go. I then did a little more research into the Cross-Origin Resource Sharing (CORS) mechanism, and found that I could use a separate API to include CORS headers in the response from OpenWeatherMap. Phew, because otherwise I would have had to scrap my work from OpenWeatherMap and find a different source of weather info. This wouldn’t have been ideal as OpenWeatherMap returns a lot of important information.

After that little mishap, I continued to pull data from the OpenWeatherMap object. Wind was next, and required me to do some digging into how I would represent the wind direction. I wanted the arrow in my initial designs to rotate in relation to the wind direction (degrees). I used Javascript to manipulate the rotation of the SVG arrow in relation to the wind direction response. 

My next problem to tackle was probably even tricker. I wanted to have a pie graph of sorts to represent the current cloud cover in your area. Luckily, I had just been working with HTML canvases in our Week 6 Technical Exercise regarding device orientation, so I had an idea of how I could do this. OpenWeatherMap returns a percentage cloud cover figure, so by drawing an arc on the canvas based on this value, and then filling it it in, I was able to get this working. 

My last job for the day was to quickly whip up the web app manifest. This is a JSON file that provides info about your web app, so that when you install it to the home screen of your device you can have quicker access and a richer experience. 

All in all, a very productive day. I definitely got a huge chunk of my prototype working. My next steps will be to look at what I can do with rainfall, as the OpenWeatherMap API doesn’t support it very well. I might have to look elsewhere for this information. I also want to get the two main menus done - the side navigation, and the home screen settings. 

I’ve hosted the app on both Surge and Github Pages as below, it’s definitely best viewed on mobile at the moment!

https://foresee-app.surge.sh/

https://gardsa.github.io/MDDN352-Project2/

[samanthagard-mddn352-blog]

Week 6 Technical Exercise

Task: to create a simple mobile web page that displays the current location and orientation of the mobile device.

https://gardsa.github.io/MDDN352-LocationOrientation/

My webpage asks for the user’s current location, and once it receives this, it places a marker on the map, and displays the latitude and longitude of the position. It also calls Google’s reverse-geocode API which takes a latLng position and finds the nearest address. I display this under the latitude and longitude values.

I used one of the device orientation examples given in the task sheet to implement the Orientation API. It takes the devices alpha, beta and gamma angles, and uses these to manipulate three different shapes defined using Javascript inside an HTML canvas.

[samanthagard-mddn352-blog]

Project 1 - The Nitty Gritty

I started figuring out the initial content I wanted to include in my site - opting for a more technical proposal as opposed to a promotional site. I felt like this would leave me more room to discuss the technical reasonings and capabilities behind 4C. 

I used Github for version control and Surge to host my site.

My process behind building the site is a little all over the place, I had a set style in my head for how I wanted to present my information, so I almost started building it before I had all my content. I eventually realised I need more imagery and text before I could continue working on it.

I made my clickable mockup in Adobe Experience Design, which gives you the option to embed the prototype in your website. I thought this would be a great way to give viewers a real feel of how 4C would work.

I also really wanted to experiment with some Javascript libraries that would allow to me create a modular interface - also knowing that I would eventually have to work out how to do it, I thought why not now?

So I looked at InteractJS and Packery, and eventually settled on Packery as I felt it had more context on the web. It took me about 3 hours, but I have a working prototype of the drag/drop functionality I want to achieve with 4C. 

I definitely wanted to include more about harnessing the Metservice/BloomSky API options, but need to delve a little more into how these work, especially as I will want realtime weather information. 

Overall, super happy with how my webpage turned out. I feel it really details the aesthetic and idea behind 4C. 

Take a look: http://foresee.surge.sh

[samanthagard-mddn352-blog]

Project 1 - Planning the website

The following are bunch of my planning notes, some ramblings for the website content, and an article or two I found relevant/interesting. My progress on the making of the website can be found on the Github repository.

Name:

Foresee/4C

Features to include: - smooth scrolling - header resize on scroll - modular UI example - interactive XD mockup

Content:

Aims: To provide a weather forecast experience that is personal, local, and easy. To offer users the ability to customise their own interface.

Target Audience: Everyone.

Technical Construction: 4C will be built as a web application, meaning users will not have to download an app, so that it can be used on as many devices as possible. This means it will be built using HTML5, CSS3 and Javascript. It will harness relevant Javascript libraries such as InteractJS and Packery for the module functionality, as well as the APIs of Metservice and BloomSky to retrieve the weather data.

Visuals

Visual Direction - talk about colour scheme and font choices - Noto Sans good for big block text such as numbers and headings, Roboto good for paragraphs/lots of text

User Interaction Flowchart - whip up a quick diagram (including sign up/user on boarding process)

Customer Journey Map - recycle old diagram

Wireframes/Mockups

Statement of intent (app's intended functionality and target audience, context/situation in which the target audience might use the app)

Functionality: - Get device location as accurately as possible - Get Bloomsky/Metservice data for that location - Displays relevant, chosen data to the user

User groups: - anyone who wants to know the weather

Statement of intent: - 4C fetches your nearby weather, and then displays the forecast you choose to see. - 4C finds out your nearby weather, and then displays a custom forecast built just for you. - 4C displays your weather - your way.

Context 4C is a weather application that offers users the ability to customise their own interface. The problem with current weather applications is that they don’t display the information users actually want. On the contrary, weather websites often provide too much information, and it takes users too long to understand and process what they are seeing.

4C is targeting the gap in this market - allowing users to select the weather components that matter to them. The landing screen depicts a maximum of four weather components which can be changed at any time.

Modular interface - https://www.smashingmagazine.com/2016/06/designing-modular-ui-systems-via-style-guide-driven-development/

User Interaction Flowchart

User Personas

Customer Journey Plan

Modular Interface Functionality

- Modular design encourages us to think and design a UI and UX in patterns. For example, instead of designing a series of pages or views to enable a user to accomplish a task, we would start the design process by understanding how the UI system is structured and how its components can be used to create the user flow. - Modular design is about breaking down a design into small parts (modules), creating them independently, and then later combining them into a larger system. - This is great for consumers because they get to customize the system to fit their needs

Modular design requires breaking down a design into small parts (modules), designed each independently, and then later combining them into a larger system. Modular UI and UX patterns will be followed to create 4C.This means creating a structured UI system, and understanding how its components can be used to create the user flow. This will allow users to customise the interface to fit their needs.

Drag and drop the weather component modules to experience how 4C will utilise Packery and Draggabilly Javascript libraries to achieve a modular UI.

[samanthagard-mddn352-blog]

Project 1 - Research Phase

After refining the survey content, I posted the link on Facebook, and in my work Slack channel. In 24 hours I had over 100 responses which is absolutely ridiculous. In the past I’ve struggled with getting people to take surveys, and was only hoping for 30-50 responses over the week, so this is great.

The following is a breakdown of the survey findings that I feel are relevant to my project:

Weather Forecast Apps and Websites

I asked responders to tell me what websites and apps they currently use for weather forecast. 79% currently use the Metservice website, while only 32% use the Metservice app. I found this interesting, but explainable as 61% of responders used native OS weather apps instead/as well.  So there’s a preference for the native apps over downloading the Metservice one. I will look into this further to determine what could possibly deter users from the Metservice app as I don’t have it myself.

I then asked what interface components people liked to see in a weather app. The most popular component was ‘numbers’ with 82%, but comments were made that too many numbers can be confusing. After that, 55% of responders liked to see imagery and icons, and 44% wanted data visualisation. This tells me that while people like to see figures representing total rainfall, temperatures, and the like, getting a quick message across with icons and imagery was also important.

Weather Forecast Breakdown

I asked responders to rate the relevance of the six main weather components (temperature, rainfall, wind, pressure, humidity, and cloud cover) from 1-6, with 1 being the most relevant, and 6 being the least relevant, to them and their daily life. These came back with the relevance scores (combined relevance ratings divided by number of responders) of:

Temperature: 2.42

Rainfall: 2.83

Wind: 3.06

Pressure: 3.87

Humidity: 3.57

Cloud cover: 3.49

These scores indicate the total relevance across the survey sample, with temperature being a good 0.4 more relevant than the other 5. However, when looking at what people rated as their most relevant component, temperature was rated twice as many times as the second most relevant component - rainfall. What this tells me is that the majority of people can look at the temperature and decide how this is going to affect what they do with their day, even if they don’t have any of the other components available to them. There’s a lot more that can be obtained from these results, but once I have planned out my app idea a bit more I will come back to these figures.

I also asked responders if they were interested in any other weather categories (marine, surf/beach, boating, tides, ski fields, moon phases etc.). There was a variety of interest across the responses, so this tells me having options for people to choose to see what interests them is very important.

Weather Habits

I wanted to know the reasons people checked the weather, and 85% of people use the forecast to help them decide what to wear. 50% of people also used the forecast to gauge if events/activities would be on or if they would go to them. A number of responders also mentioned weather forecasts were important to their work - builders, flight planners etc. 87% of people checked the weather forecast in the morning, while only 24% checked incrementally throughout the day. This raises an interesting idea. In the morning, people are often rushing to get to work, school etc. If they are checking in that short time, they will want to be given the information quickly, without much effort or processing required on their part. Whatever I create needs to cater to this.

86% of responders were interested in seeing a long-range forecast, with nearly 50% of them wanting to know 5 days ahead. There were a few comments about how long-range forecasts could be unreliable or change in that time, but the overwhelming majority were interested in having an idea of what could be coming later down the track. This relates well to the question I asked  “How does checking the weather forecast change how you plan your week?”. Most of the comments were of the like: “i schedule my plans based around what days are meant to be good and bad”, so if a student was planning to get some study done for example, they would look at the weather and if there was a rainy day coming up, would plan to get most of their work done then.

Interfaces

I decided to provide some examples of existing weather app interfaces - where two apps would be displaying similar information in a different way - and asked responders to pick which option they preferred. All three of the comparisons had a definitive preferred interface.

The first comparison depicted information for a daily forecast. As you can see, they both use numbers, graphs and text. However, 58% of people preferred Option 1. I believe this is due to the text elements and icon elements used. The text is clean and contrasts well with the background. The icon on the left clearly shows that rain is expected, and the icon-number relationships on the right concisely detail the relevant info of the day. Option 2 seems to have a focus on rainfall - I imagine on sunny days this interface would not be particularly useful. However, the wheel at the bottom of Option 2 is innovative in that it allows the user to explore the weather coming up in the day.

The second comparison displays two versions of a long-range forecast. Again, Option 1 was preferred, this time by 71% of responders. Personally, I prefer Option 2, but I can see why the majority like the first interface. More information is given in the form of icons, rainfall, and high/low temps for the whole week. The second options shows much less information - only the highest temperature for five days. However, temperature is the focus of the second interface - it displays the current temperature as well as the five days ahead. It also uses colour well to indicate the difference in temperature across the week.

The last comparison was inspired by my interest in using colour to represent weather conditions. Both these apps aggregate a number of weather component information and then display certain colours based on that information. Again, Option 1 was the most popular with 61% of the votes. I believe this may not be due to the actual colour used, but the interface overlaid on the colour itself. However, the simple line visualising temperature and precipitation by the hour is a very innovative way of displaying two components in the same element. Option 2 uses a ‘by-the-hour’ strategy to display weather information. Unique hourly colours are calculated based on temperature/humidity/sunrise and sunset times. These are both visually stunning interfaces with complicated data displayed in a simple way.

While all these interfaces have fantastic elements, they all assume what the user wants to see. What I want to do with my app is let the users decide for themselves what is displayed on the interface. This creates a personal experience, as well as upping the interactions between the user and the application.

Conclusion

Hindsight is a wonderful thing - after obtaining these results, I decided there were a few things I would have liked to do differently. I should have given age brackets, and occupation categories to make it easy to categorise groups of people, and eventually analyse more specific sets of data. Alas, I did not. I also would have liked to ask if people did/didn't use weather apps/websites, or which they preferred to use.

I got a great comment from one responder:

"This is just as a side note but the main reason why I don't use apps is because they don't have the info I want- often the websites display more. It would be really cool to be able to have an app where you can customise what it shows you on the front screen so that you get the most amount of Information about what you actually want. Most of the time apps have very lots of general non-detailed things, and I mostly want very detailed things about specific things!"

This is something I  considered myself even before sending out the survey. From the very varying answers in relation to 'weather component relevance', it's obvious that while some people are very interested in knowing the temperature and rainfall, others would rather know about the wind and humidity.

Therefore, my current idea for this web application is to create a modular interface. A user would sign up (still pondering the authentication/user id side of things) and then would be asked what weather components they wish to see. The app would then display these on the interface. To take this further, each 'weather component module' could be able to be dragged around, resized etc. I found a cool Javascript library called InteractJS, which would allow me to do this. This would create a very personalised app, which is what both Metservice AND the public want.

In terms of the user login, I believe the term I discussed with my tutor was "user onboarding". This refers to the whole flow of drawing in and retaining a user, but the most important part for me will be the initial sign-up and preference selection phase. I'm still weighing up as to whether it would be easier to have separate user accounts for each user, where all their data is stored on the account so they can access it across multiple devices, or whether something like caching or cookies would be better.

[samanthagard-mddn352-blog]

Project 1 - Ideation

Metservice

current weather app/website presents all this data to you - some of which you might find useless/don’t want to see

a personalised weather app with a user friendly UI which gives you the option of displaying what you WANT to see

for example, someone who lives and works in the city would be concerned with temperature and rain forecasts to help decide whether they will walk/drive/catch public transport/bring a rain jacket

other examples could be someone who enjoys extreme sports such as skiing/windsurfing/skydiving and would want to know specific weather forecasts such as snow and wind etc.

having the option to customise your home screen based on what is relevant to you, with a user friendly UI that reduces the amount of numbers you have to process yourself

another cool feature would be to set up alerts - e.g the app could let you know if its about to rain in the next hour or so, or recommend the best day of the week to go out for a bike ride or picnic with your mates

hyperlocal weather information

could be entirely text based - sometimes you don’t actually care about animated raindrops etc. you just want to know if its gonna rain or not - honesty/transparency

data visualisation - maps (mapbox?)

precedents: Dark Sky, Poncho, Authentic Weather, Party Blue, Sun (Dark Sky API), Partly Cloudy, Solar

Survey

I’m going to create a survey to find out what people actually want from a weather app. I will try to get around 30-50 responses from a range of different people - students, working professionals, parents, teenagers, sportspeople etc. By finding out what information is most important to people, I will be able to start planning how I will structure my app.

Questions

What weather app/s and website/s do you currently use? (two separate questions - try to gauge if more mobile or desktop users)

For what reasons do you check the weather forecast? (e.g. daily travel/sport/forward planning)

What are the most important weather forecast components for YOU? (pick from classic components, then separate question for other components)

What weather forecast components do you not care for/find useless/don’t understand?

What about current weather forecast websites/apps do you find confusing? (too many numbers/useless info/complicated graphs)

Do you understand certain weather components/what they mean for you/your daily life?

What time of day do you usually check the weather? (in the morning before you leave/during the day/planning ahead)

How does checking the weather forecast change how you plan your day/week?

Do you care about a long range forecast (5-10 days) or are you more concerned with the next hour/the rest of the day/tomorrow?

Do you find data visualisation useful? (Do you like to see your weather forecast in graphs, images, icons, or do you prefer plain text?)

Have some mockups for people to decide between - what UI do they prefer/what is more clear to them?

Weather forecast components

Classic - six main components

temperature (low/high/current/feels like)

rainfall (rain radar)

wind (speed/direction)

humidity

pressure (high/low)

cloud cover

Other

marine (coastal/recreational)

surf/beach

boating

tides

national parks

ski fields (snow fall, snow base)

moon phases