DSDN 112: Potential Nav System Formats

So, I started to come up with some concepts for how I'm actually going to design the interface itself. At present I'm just looking at some basic ideas of how to design the actual process and how the interface would be presented.

I was thinking about an actual GPS interface, and one of the reasons it wouldn't work is due to the height difference in buildings. A GPS would never know what floor you were on, and wouldn't be able to give you directions, hence a navigation system would have to rely off a triangulation method when inside a building, or a series of pre-designed rooms. Given that a building is unlikely to chance much internally, all the data could potentially be stored in a mobile app and then recalled when it's required.

Considering I did an augmented reality project for 101 last trimester, that was one of my first port of calls for this project. Using the real world and a system to guide you indoors would be phenomenally tricky, and would most likely have to rely off a whole series of tracking systems indoors.

High-vis points, possibly emitting an infra-red frequency for the augmented reality glasses could provide cues as to where the user is, as well as also providing a reference point for the arrows to be generated so that they stay in their rightful place in the "real world".  Other elements of the interface could simply be overlaid at a static point (such as a map, time, and final destination point) The final destination point could be overlaid in terms of a vectored location, as opposed to actually being exactly there. What I mean is rather than have it shown where it truly is (vertical distance-wise), just show were it is on a two dimensional plane (relative to you in two dimensions, like a compass).

This is a little concept design I did for the augmented reality idea. In this system, there could be a Call Of Duty-esque minimap on the right that shows the surrounding area in terms of a simplified map, as well as the users location. What I thought would be a good bonus is that the map rotates with the user, just like in a video game. That way up on the map is always directly ahead of the user. This would be extremely simple to control by way of an electronic compass.

One of the elements I built into my 101 project was the ability for the augmented reality glasses to pick up details about the surroundings, and provide relevant data on-screen. This kind of information would be user-customisable, and would allow for the user to essentially design their interface using a set of pre-made elements. This type of customisation is incredibly desirable in products nowadays, as we see through the ability to change phone backgrounds and icon arrangement, as well as a huge variety of protective covers for one's phone.

The directions that I've put in this design would be locked to the environment, rather than the glasses. Unlike the minimap, which is locked to a specific coordinate on the x-y plane of the glasses, the relevant data on surrounding elements of the environment and the directions would be locked to those elements of the environment. So the directions up the stairs would move across the screen if the user turned their head, and the data about cheap coffee at Wishbone would move with the wishbone sign.

The idea of these elements moving with the environment is that they are tied to the environment, not the screen.

For the mobile phone app, the system is far simpler to orchestrate. Dropping the high-tech technology, I wanted to in stead design a system that could function independently of a network. Having the data and the program able to use that data in one app would mean that the program could function completely separate of any high-maintenance tracking systems. Admittedly it wouldn't be nearly as cool, but that's okay, it's about functionality and usability.

For this interface, it's based around a very simple system. It could essentially be a dumbed down system of Google maps. As opposed to typing the address you're looking for, you just scroll through the list of buildings, and then after choosing a specific building, the list of rooms is significantly shortened, and then the user can make a selection. Once the user has chosen a destination, they select their current location, which, if it worked with the assistance of Wifi detection and the GPS network, could complete itself. Otherwise, the user could select from a series of locations, again with the ability to choose any specific room, or also to choose from a few common places and large locations that would be arranged at the top of the list.

One the app has the data it needs, the user merely has to select calculate route, and the apps works out the ideal route, and then pulls up a relevant portion of a map of Kelburn. The app could hen adjust the map so that it only shows the parts of the map that are needed for the journey, so as to minimise confusion.

A bold line detailing the direction of travel would definitely then be beneficial, along with small names for each of the rooms the the user will pass along the way. Points of interest would be highlighted as well using recognisable symbols.

One function that could also be very useful would be to allow the user to switch between written instructions and the visual map. Since some people work better with visual instructions and others find written directions easier to follow, this would certainly allow the program to be used by both types of people. Having the ability to switch back and forth between the two would also be ideal, since some people find a combination of the two directions even easier.

Definitely more designs for the navigation system still to come! Stay tuned!