views:

20

answers:

1

Hello,

I'm working on an app for iPhone, and the data model looks a little crazy - 16 entity types. Could you offer any advice for masking complexity like this from the user? I know all these need to be there, but I'm trying to make it look simple, cause otherwise people will not understand.

The Tricks I have figured out so far:

My app is a bit secret in nature (in development) but use for example an app that deals with nature trips, i.e. hike, mountain bike, skiing, etc. Say I would have an object for a certain journey, i.e. by bike, through the rocky mountains (Journey: Mode of transport, location). Then I would have a different object type to store a specific journey, i.e. This january, do the rockies bike trip (Trip: Date, Journey).

Trick 1: I found that the user doesn't really grasp the difference between the two objects I just mentioned (trip and journey), and generally wouldn't care if I called them both "Trips" on the UI. (Try explaining the two distinct objects to a non-programmer, 25 minutes you'll never get back).

Trick 2: certain things, like for example pieces of camping equipment, may be objects to me, (equipment name, weight) but to the user they are just words, so I treat them as such and when they type it in my app says "You've never mentioned 'tent' before, how much does it weigh?" Then they tell me, and I have created an object without telling them it exists.

These kinds of tricks are what I'm looking for, my app needs to reduce these 16ish objects into maybe 3-4 the user is aware of, the rest hide in the mists, so anything I can get would help.

Thanks.

P.s. before you say it, I know, keep it simple, shouldn't have so many object types, etc. Just looking to find a workaround for this rule (guideline) with coffee and genius.

+2  A: 

Stop trying to look at it from a data point of view. Rather, think about what the user is trying to accomplish with your app, from the most basic point of view.

Your nature analogy is too vague for me to help any more, maybe expound on that?

Reed Morse
Seconded. Don't let the data model define the UI.
Matt Lacey