Case Study 1: Get Help

Actually, this app sounded so much like an idea that I came up with for assignment 1 too. Just that it wasn't developed or even brainstormed upon as much as Let's Goal which we eventually settled upon...

Help app (by JG) - HOLD (or unless someone else wants to develop this with me)
- Allow people to post requests for help - public or only to friends
- Earn points by helping others
- Or earn points by helping ppl to help others (by forwarding requests)
- “Helped” person gets to award points to the people who helped him/her
- Points can be used as broadcast (xxx helped someone today)
- “Classifieds” allow people with more points to have their requests higher up on the global list.

But it's really interesting to see that the same idea had actually been done many years back! Really super surprised...

So having had the answers posted on IVLE, I think most of the lessons talked about were really quite right. Sometimes developers want a feature to stand out (we have a way to store this statistic! let's have a page for it!), want to experiment with something (hey twitter bootstrap tab pills look good. how do I use it?) or sometimes it's about totally not understanding the interaction between the user and the app (oh so users actually really use it like this?)

Those stuff in brackets up in the previous paragraph, I've done it all. Pills? Let's Goal main page nav buttons. Statistic? Let's Goal ranking page (heck, even my own app requirements up there). But it's not like I've learnt from it, just that I become more aware of it, and consciously avoid it if I remember.

Anyway, the focus of this post is on the Get Help mobile app... back to topic.

----

In such a mobile app, we have certain assumptions about the user and device:
- Screen size limited (the screen's not as luxurious as iPad, that can probably use the non-mobile optimized app since graphics and stuff are barely minimal)
- Network IO limited (restrain use of hosted graphics and resources, try to be app-embedded if critical)
- Users are probably going to encounter the app via the FB app, so we assume they know "how it works"

Since this is a FB social app, we definitely need a login screen - a "Connect to Facebook" button. This is essential since the hosted data - the requests, friends - all comes from Facebook. If the user isn't a user yet, a sequence to connect to Facebook should be necessary.

The page after login/registration should lead the user to the equivalent of the website main page - where you get to enter a new request (Figure 5 in the Background document):

• "I need" box for new posts (phrasing should be consistent)
• Leads to a page to complete the new post:
• Trim the "I feel" and "Rewards" sections
• Another section for friend's requests.
• Large tappable region (of course)
• Goes into a new page with full-page details of the request.
• Needs/Rewards (as a tab/page)

Network data for the mobile app should be on a user-pull / event-triggered basis, eg refresh on new post, explicit reload. The images that are used could be part of the app and not requested from the network, to reduce the overhead.

Small number of push requests can be used to create user engagement, eg to alert them that someone has received help. Or someone has indicated help for their help requests.

This seems like a basic featureset for a mobile app, allowing you to provide a consistent functionality for the mobile app (post requests to friends, and view friends' requests).

----

It is really weird and surprising to see some idea you had, actually being realized 5 years ago and not knowing of it...