[iOS] New Report prototypes

[Marius Constantinescu]

Hi all,

In my process of improving the design of the GeoReporter app for iOS, I got to the New Report part. In this screen, I think that the process of going back and forth to complete all the fields in a report can become annoying. I have created two prototypes, with two different approaches. Can I get some feedback on them? Which one would you think would be best?

The prototype in Paged.jpg will be using a PagedViewController. Each page will be responsible for one field. The way a page will look will not be very different than the way it looks now. The new part here is the fact that instead of using the navigation bar on top to go back and then select another field of the report to fill in, here we use a Page Controller (small bar at the bottom of the screen), which takes us directly to the next page (or previous one). Gesture navigation can also be implemented, swipe left or right could be back or next. In this prototype, the number of taps a user has to perform in order to complete a report will be reduced to almost half (one tap to get to the next field, instead of two, as before).

The second prototype, in Scrollable.jpg, merges all the fields of the report in one long tall view. Each field is grouped in a "cell". Tapping on a cell scrolls the view, so that cell is at the top of the screen. In this prototype, all the report is condensed in one single view. This one reduces even more the number of necessary taps to complete a report (you have direct access to all the field; all you have to do is scroll).

For both prototypes, I was thinking to implement custom radio buttons. I think this would be a better choice than the picker, because many users and developers (including me :) ) don't really like pickers. They seem heavy, are too big, take too much space, don't let you see all your options at once and so on. I would replace the pickers with custom radio buttons. Also, since in most cases, a multi value list actually contains only "yes" and "no", I was thinking or this particular case to use a segmented controller to choose between those two, and not the radio buttons or picker (radio buttons for yes or no wouldn't be that bad; but I wouldn't use a picker to display "yes" and "no"). What do you think?

Thank you,

Marius

[Rajul Bhatnagar]

I was thinking of doing something similar for android.

With a paged view it can get annoying if I don't really want to fill in all the details so I personally prefer scrolling.

Now with scrollng If we display all the choices inplace it can become a really really long list.

So I was thinking of showing things like adding description,and yes/no type of choices and single choice using spinner inplace and using Dialogs for multichoice options.I think dialogs would work fine for this use case.
What do you think??

--
You received this message because you are subscribed to the Google Groups "open311-mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open311-mobil...@googlegroups.com.
To post to this group, send email to open311...@googlegroups.com.
Visit this group at http://groups.google.com/group/open311-mobile.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Rajul Bhatnagar
Btech Computer Science & Engineering
VIT University Vellore

[Rajul Bhatnagar]

Also we could use something like an accordian for multichoice options instead of a dialog to reduce the scrolling and avoid using dialogs.

[Cliff Ingham]

Both options seem reasonable.  It might just come down to personal preference.   I originally avoided scrolling the report view because, often, the questions we were asked were very long strings.  That much text, plus the single or multi-choice took up a lot of space.

In your mockup, it seems you're well aware of the varying length of question strings, though.

Rajul and Marius, are you both thinking a scroll view for the report is the way to go, then?

[Cliff Ingham]

Custom radio buttons sounds great.  Do we want to share artwork?  So far, I've been trying to keep the iOS version looking Apple-y and the Android app looking Google-y.

[Marius Constantinescu]

I would also like to keep them separated. It makes sense for the design to be similar (for example, if one uses a scrollable view for the report, the other should use the same and not the paged view). But I wouldn't go that far as to make them look exactly the same. Personally, I hate iOS apps that look like android ones and the other way around. I found last night an iOS app which used a custom navigation bar placed at the bottom of the screen just to have the 'back' button like an android app. And a custom tab bar at the top of the screen. I didn't like it at all.

On the same note, regarding what Rajul said, I know that using dialogs for input from the user is quite common on android, but I haven't really seen this approach on iOS and I wouldn't use dialogs on iOS.

Sent from mobile

[Rajul Bhatnagar]

Ya surely the look and feel of the apps should be native to the platform but the experience shoud be the same. Using Dialogs for input should be avoided even on android except for special cases.

Is there a spinner/dropdown like view in IOS(Something like this and this)?? We can use this for both single choice and multi choice selection. It will save space and avoid using dialogs.

[Rajul Bhatnagar]

Although for multiple choice I would prefer using something like an accordion instead of a spinner.