For this assignment we were asked to examine the existing MLS/REALTOR.com property search function for problems, and brainstorm some possible solutions for both the web and mobile devices. Then we were asked to choose the best two designs and to iterate them into a more presentable mock up.

First I looked at the current system and identified problem areas:

click for a larger image

1.

- Most of the menu options are superfluous, or at least layed out poorly. They take up too much space, and following the 80/20 rule, I doubt that 80% of the users use even 20% of the features.

- The highlighted portion in particular is very strange. Although prices may vary wildly in different areas, and the user’s budget may be more specific, there is just a huge list of canned values to choose from. This could be better handled with text boxes, or a slider bar with a max and min point that are both movable.

- It’s odd that the system clings to using the number of bedrooms and bathrooms as a metric for size instead of THE ACTUAL SQUARE FOOTAGE OF THE HOUSE/PROPERTY. Usually the size of the house might correlate to how many bedrooms it has. If I’m buying a house with three tiny bedrooms and a much larger house with two bedrooms sells for the same price, I want to know.

- This information doesn’t update based on the area the user is looking at which can return search results that include zero houses but does not explain why. This is useless. If there’s any houses for sale in an area, I want to know, even if they’re out of my price range.

2.

- What are these dots telling the user? They are all the same, so the only thing they communicate is location.

- Because the dots don’t communicate any information, seeing patterns in house pricing is nearly impossible.

- Mousing over a dot brings up a popup with some information on the property. The exact same information is being presented in the list on the right!

3.

- This list on the right has nothing to connect it to the location of the houses, which is odd considering that location is perhaps the most important thing buyers are looking for. Location, location, location.

- The system could include a graphic much like the one I added to make this illustration. Note: the house and the dot that I linked are not actually related.

4.

- My mistake, the dots do change colours. But what is the blue indicating? Can you tell? After a few minutes of confusion, I realised that the blue appears when you mouse over a house in the list on the right. The fact that it sometimes doesn’t go away is a bug with the system. This tiny change is almost impossible to notice, and the fact that there’s a bug that could potentially confuse users is unacceptable.

5.

- It’s pretty much just cluttered and ugly.

Brainstorming Process

Here’s some examples of my brainstorming process:

These first two sketches were for the website version.

On top, I started by making the elements of the site collapsible and a bit more streamlined. Because location is very important, I made the map the center of attention, having the map physically envelope the other elements.

The second attempt eliminated the home list sidebar altogether, relying on popups for each house. Because side by side comparison is sometimes necessary, I added a “drag here to compare” box that appears when users mouse over a particular home.

On top I kept the housing list, and attempted to have the search settings take up as little space as possible atop the list. The houses on the sidebar are linked to the map by use of rays emitting from the sidebar onto the location of the house.

The next adds pictures and pop-open information tabs. The tabs may be useful in comparing houses together, and the pictures of the houses are always present because to some users the look of a house is a very important feature. The pictures exist over the actual location of the house on the map.

The first two mobile brainstorms relied on two screens.

The top was designed without the use of a map, which can be tricky on a cell phone. The interface returns a list with pictures and brief information. Here as well I’m focusing on location, price, and size as the most important elements of a house.

The next design identifies the location with a map, and allows the user to filter data with search terms. While browsing each possible house, the search box is replaced with the house information, and the location is made obvious with a bubble tail.

Click for larger image

For a while I experimented with having the actual dot of the house location indicate more to the user than just location. I developed two sliders, one for price and one for size that would change the appearance of the actual dots, allowing the user to see information quickly without having to browse dozens of search results manually. I even tried to combine them into one meter, but I decided it was too confusing to have one meter indicate two separate functions, although it’s technically feasible.

Mobile Device Mockup

This mockup focuses on the three most important things about buying a home: Location, Price, and Size.

The user finds the location they’d like to find a home in using a map, such as Google Maps, which are already widly used on platforms lik the iPhone. The area they are looking at comprises the bounds for their search: the values for the minimum and maximum of both the Price and Size bars are the actual minimum and maximum price of the homes for sale in the area they are observing. These values update on the fly as the user pans and zooms the map. This gives a quick overview of the price range of the homes in the area and allows the user to narrow their search quickly.

Once they think they’ve found an area with homes in their price range, the user can fine tune the price slider to get a better idea of where the homes they can afford are located. The white marker indicates their desired price. The dark green just below this marker indicates homes that are very close to their desired price. Red homes show houses just outside of their price range, to give an idea of what they could purchase if they were willing to go a little higher in price. The black indicated homes far outside thier price range. The green values fading into yellow give an idea of other price options in that neighborhood.

The size in square feet is also very important to buyers. By adjusting this slider, they can get a feel for the size of the houses in the area, and more importantly, how size relates to price. The size of the houses is automatically mapped from largest to smallest to the size of dots from largest to smallest. The user sets the slider to their desired home size. Every house dot on the map has a black circle around it that indicated the user’s current size request. This ring gives context to all the homes: the user can quickly see which homes are larger than their requirement but equal price, or if a home is too small and more expensive.

A red dot that extends beyond the black ring is a home that is larger than required, but just outside the price range.

A yellow dot that is small and not touching the black ring is a small home that is much cheaper than the budget.

The ideal home is one with a green dot that fills the black ring.

If they want more information or a picture, they can poke or select a specific dot and a popup will apear with all the particulars of that specific house.

UPDATE: WINDOWS VISTA WIDGET MOCKUP! AAAAH!

After talking to Alex today in class about being sick over the weekend, he asked me to continue with the assignment and create a desktop based mockup. I decided to focus on a desktop widget for windows Vista that incorporated my previous mobile concept. This model centered on the decision making process of buying a home, namely the comparison of competing homes.  I developed a folder popup that would contain the information about a property, as well as showing where the property met or did not meet the requirements of the user.

For example, if the user wanted a home that was over 2000 square feet, but the home only had 1900, the floor space field would be coloured Red to indicate that it did not meet the requirement. This allows the user to quickly glance at a property and see how many plusses and minuses it has, aiding the decision making process.

Click for larger image

I have a few things I’d like to change: there’s no close button, I’d like clicking the address in the property info field to center the map on the property. As well, I didn’t mock up the settings pane that would acompany this. I like the idea of a settings pane that would be visible only when needed: when people are searching for a home their requirements for the home don’t change every time they visit a website, so if they visit the Realtors.ca website a lot they’ll always be typing in the same info. Can we not do this to people?

In addition, Alex mentioned some critiques of my original mobile design:

- The cirlces aren’t very helpful: they could be houses instead, and better than a circle that encloses the house the house icon could fill up with a colour to indicate floorspace.

- The colours don’t work aesthetically (I agree, and probably spent the least amount of time on them)

The following is a documentation of the changes made to my Semantic Web information map. I was working alone on this project. The piece can be found here:

Semantic Web Information Map

I will show the most significant changes made in the form of screenshots from before and after the changes. The first screenshot is before, the second after. The before shots contain the class’ critiques and my own reflections, and the after shots how the map was changed to be stronger based on the feedback.

Please note that the variation in the font in these screenshots is an error that occurred when attempting to edit this project on a mac from a PC, the inconsistency is not present in the finished piece.

The title screen of my semantic web information map, before.

Critiques:

- The flashing of the “next screen” arrow is distracting, unnecessary

- Didn’t know what the graphic on the bottom left was representing.

- After changing to the next screen didn’t make the connection that the upper blue was the web, and lower orange was semantic web examples. Need something to tie screens together.

The title screen of my semantic web information map, after.

Changes:

- Arrow no longer flashes, but has text to draw attention to its function.

- Added a brief explanation above each diagram.

- Added lines emerging from web/semantic web buttons to add a visual connection to the next screen (this theme is continued throughout)

The second screen of my semantic web information map, before.

Critiques:

- Again, no connection between elements across top and bottom.

- Didn’t know what the smiley faces meant.

- Flashing of elements that have mouse-over popup is distracting while trying to read (the outlines fade from white to grey)

The second screen of my semantic web information map, after.

Changes:

- Bridges connect bottom and top stages of example.

- Text placed in an easier to read position (from vertical in gap to horizontal on bridge).

- Added text explaining smiley faces are users so it’s immediately obvious.

- Changed fading in and out of mouse-over elements to be twice as slow so it’s less distracting.

The semantic web example screen of my semantic web information map, before.

Critiques:

- Arrows are messy, difficult to understand meaning behind them.

The semantic web example screen of my semantic web information map, after.

Changes:

- Removed arrowheads and connected lines to computers directly as they are in the web example above to make the graphic style more consistent.

Reference List:

Herman, Ivan (2009). WC3 Semantic Web Activity. Retrieved February 24, 2009, from World Wide Web Consortium Web site: http://www.w3.org/2001/sw/

Wilson, Tracy (2006). How Semantic Web Works. Retrieved February 24, 2009, from HowStuffWorks Web site: http://computer.howstuffworks.com/semantic-web.htm

(2009). Semantic Web. Retrieved February 24, 2009, from Wikipedia Web site: http://en.wikipedia.org/wiki/Semantic_Web

Last week I drew some more sprites, including a smoother Suplex animation for Bruno, a Power Bomb animation, Press Slam animation, and a DDT.  Balroop has already implemented most of these features, as well as the ability to throw opponents and objects that have been lifted above the player’s head. Oh, I also drew a throwing animation.

I drew another enemy for the second level, the Football Player. This is taking a long time.

LAST last week (I missed the posting because I was away for Easter) I drew the backgrounds for the the second level. This didn’t take as long as the first, because it’s mostly just a series of scrolling backgrounds; the level doesn’t scroll at all. I also drew the sprites for another enemy in the first level, the Mall Cop.

Balroop and I also talked extensively about the state of the project, and how much we’ll be able to complete by the deadline. It wasn’t looking good, so I asked Eric for an extension, which was approved last week in class.

The last week we’ve been ramping up to the digital prototype we need to playtest with people. We finally got some sounds implemented, but no music has been delivered as of yet. I drew some more of the background for level 1, and some sprites as were needed to finish implementing the enemy AI. Balroop and I met several times throughout the week to discuss what needs to be done for the prototype as well as the final product, and planned the next few weeks worth of work. It’s going to be a lot, because we don’t have very much support from the other members of the team, but we should be able to pull it off if I don’t do anything fun for the next four weeks.

Puzzle League

Puzzle league’s front-end interface is mostly just menus with text. There’s nothing special, no fancy graphics or neat effects, just sort of a barebones interface with happy music and satisfying sound effects for menu selections.

In game, the interface is arranged into columns, with the player’s field on the left, the stats (timer, points, game speed, etc) in the center, and the opponent’s field on the right. There’s not really much to talk about as far as innovation here.. It’s pretty standard interface. As mentioned previously, this game has no story or cutscenes, or anything to convey to the user except the raw gameplay.. I feel sort of uninspired writing about it, except that it very competently gets the job done and doesn’t interfere with gameplay in any way. There are a few options to customize in the interface, but they mostly relate to how animated the interface is if you find it distracting while trying to play.

Mario Galaxy

Galaxy takes all the recent developments in interface HUD design and combines them into one. The information panels (health, coins, etc) hide when you don’t need to see them, leaving the whole screen open to run around on. The elements are strategically placed so that the most important element, life points remaining, is in the center. I could go on, but Smash Bros. Brawl was released today, and I want to go play it.

This week was spent trying to get the digital prototype on track. This was hampered by team member’s work schedules, and one team member who was sick and hospitalized briefly, but did not communicate this fact to the rest of the team.

I drew some sprites, came up with some concept colours for the main character, and drew most of the graphics for level one.

I think the prototype is on track based on our progress so far… Not much else to say!

Puzzle League

I’m starting with this one because it’s “easy”. Puzzle League has no story, no cutscenes, no levels, no locations. The blocks are always the same graphic no matter what difficulty level, or game mode you happen to be playing. The only slight variation on theme happens when the user enters the option menu and has the option to change the background graphic. These graphics are all repeating textures; wallpapers, rather than actual pictures.

The reason for Puzzle League’s lack of theme is confusing, considering its predecessor Tetris Attack had a full story mode, a character select screen, and multiple levels. I think Dr.Mario & Puzzle League being released as a budget title caused the studio to lose any interest in putting in extra effort to add any themes.

Mario Galaxy

Mario Galaxy, on the other hand, has many, many different levels. In fact, each “level” itself may have multiple locations, themes, and landscapes contained within it. These changes of theme are allowed for by the planet hopping gameplay. Players may be slipping around on a donut shaped planet covered in ice, and the next minute be dodging advancing flows of lava.

There is little explanation to tie these planets together, but they usually fall under a set of themes (fire and ice, grasslands, ocean exploration) that are related in some way. The game is also short on story advancing cutscenes, although there is a room you can go in on the main hub world to hear the backstory of the game as it becomes unlocked when the player finds enough power stars.

The level design does a very good job of keeping the player engaged, considering the fairly limited number of actions available to them (jump, spin, shoot stars), planets with interesting shapes, or gigantic enemies, or unique puzzle. These elements are often combined under the planet’s theme to tell a small story of it’s own. For example, I’m a little blurry on the details as I played this level quite a while ago, but one level has the player stomping on a series of pegs so that they jam into the center of the planet, agitating a giant worm that emerges and creates a bridge to a new planet with it’s body. I can’t really remember, but I think later on Mario must fight the fully agitated worm. These little touches add magic to the Mario universe, more so that just having the pegs cause a bridge to be magically lowered, say.

This week was spent… you guessed it… Drawing even more sprites! I worked closely with Balroop, hashing out gameplay feel and controls, tweaking old animations and creating new ones we need to get the prototype on track for week 10. I also spent a significant time trying to get the other members of our team to produce something to add to the game, namely music and background elements. Although, in the end, they did not. I’m starting to worry about the logistics of a two man team completing a full game.

This week  was spent drawing frames of animation for the main character, Bruno. Several of the most important animations have drafts complete: walking, grabbing, jumping. There are still more to be roughed out though, including getting hurt, being knocked down, running, grabbing while airborne, and of course, all the wrestling moves. It seems like a lot, but I feel we got a good enough start on this process that it’ll be doable.

I also met with Balroop in class this week and hashed out some more ideas about what will work with the game engine we chose (Game Maker) and what will not work. I can’t remember all the details but I have them written down somewhere. The digital prototype is looking promising! I also talked to Bowen about getting music on track, he hasn’t started working on it yet, but is looking for instrument files to compose with. At this point I’m concerned about the status of the game’s music and SFX, as none of the work assigned on that front has even been started, and if nothing is completed this week we’ll have to re figure that aspect. As well, the backgrounds for the levels, which are currently Arlen’s task, have also not been started. Maybe my organizational skills are being called to task. Or maybe some people are lazy.