macOS hey developers...need some advice pls!

[Keebler]

hi folks,

Here's the dilly:

I have 2 ideas for apps. not sure if they're great or not, but I believe they're useful.

Huge problem: I can't code to save my life

SO, I know a few local developers and I've already talked with lawyers about having NDA's in place, but here is my dilemma:

I can envision my app; I have an idea of what I want all the text and screens to say and look like, but I'm absolutely clueless as to where to start mapping this out.

My question: if you're a developer, what do you want to see in terms of plans and/or documents to help communicate my ideas to you? Is there a standard protocol to follow or does it really differ depending on the developer/programmer and what they like to see?

ANY advice is welcome.

Cheers,
keebler

 

[Catfish_Man]

Personally I rather like the concept of "user stories" from the agile development philosophy. http://en.wikipedia.org/wiki/User_story

 

[LtRammstein]

Be with the developer the whole way. Don't give your vision to them and make them figure it out.

 

[garethlewis2]

I'd be worried if you can say, you can envision the screens. That gives me a large warning of you know what you want it to look like, but now how it should work. The developer, is not interested in how it looks, but how it is meant to work.

If it is a web-app. Then that is probably okay, but if it will be doing something slightly more complex than loading text files, I would put down as either a flow-chart or some other diagramming method, what you would expect the user to be able to do with the program, and how these actions would function. Easier than writing a rather boring document on the subject.

 

[Keebler]

thanks for the replies. great feedback!

Catfish - love the idea of user stories. I'll do that

lt R - i plan to be with them. I'd like to learn more about the process

gareth - I can envision how it works too. I honestly just can't program...very frustrating. I have a pad of huge graph ppr that I use for flow charting DVD menus etc.. so I plan to do the same with my ideas as well. Maybe a combination of the graph pad and user stories.

Thanks. I'll let you know if this someday comes to fruition.

 

[iSee]

If your app is UI driven then storyboards are a good way to document much of its functionality.

It sounds like that's what you are thinking with the graph paper, though it really doesn't need to be all on one piece of paper (not that an overview wouldn't be nice.)

In order to get a sufficient amount of detail into your spec, diagram each screen/page/form/dialog box/whatever that will be presented to the user. To begin with, concentrate on including all UI elements. Don't worry about the layout so much initially -- you can come back later and straighten out the layout. It's important that you get every control, widget, label, title bar, etc. on there. Include everything--even standard OS things like a window's close button.

Above each diagram, state what the form/page/whatever is for. e.g., "on this dialog, the user can view and edit their preferences."

Below each diagram, list every control the user can interact with and state what happens when the user performs each action. e.g., when the user clicks the OK button, the changes are saved and the dialog closes. Try to be as specific as possible (but be concise, also).

Obviously, if a particular UI element or group of UI elements appear on multiple screens/pages/etc you can document it once. Be careful, though, if its functionallity is different on different screens.

Try not to assume anything, even if it seems obvious to you.


Of course not everything can be well documented just by documenting the UI. e.g., think about smartlists in iTunes. Even if you document the dialog that is used to configure a smartlist, you will not have really described how a smartlist works. Review your document for things like this and describe them as clearly and completely as you can. Try to write in the form of a list of straightforward statement rather than long convoluted sentences. Diagrams can help. Be consistent about naming things. If you refer to a standard thing, try to use a standard name for it (e.g. call a window a window). If you refer to something particular to your app, come up with a consistent name to use and be clear if the term you use could be confused with something else.

^^^ that should cover the functionality of your app. You should also cover your app's requirements. Try to list everything you expect from the app.
- system requirements (or browser requirements)
- responsiveness in key situations, if that's critical (don't make the requirements overly restrictive or you may make the app much harder to implement than necessary)
- look and feel
- any standards that it should follow/implement/etc.

You might want to read Apple's Human Interface Guidelines documentation:
http://developer.apple.com/document...al/AppleHIGuidelines/XHIGIntro/XHIGIntro.html
(you might need to sign up for a developer connection account to see this --it's free)

Actually, even if your app isn't OS X software, this is a good general resource for designing software. If your spec addresses all the issues it raises, it will be a better spec than most out there!