UI needs some TLC

[gengkev]

The navigation bar looks pretty bad, first of all. And the list and detail views are a little plain; they could use some color and Material inspiration. Make things look pretty!

[gengkev]

(see designchanges branch) clearly i'm not a designer

[gengkev]

there's just the challenge of having to convey a lot of information at once, efficiently, clearly, and consistently in a rather constrained space.

ScheduleFragment (list of blocks)

in the eighth schedule view, i was thinking of displaying one section for each day, with however many blocks there are. this is pretty much done, actually, but i'd like to focus more on each day as its own entity, as below.

what's most important to know about each block and activity?

1. when and what block it is (e.g. Friday A Block),
2. name of currently selected activity (if any),
3. whether that activity is cancelled / has changed rooms,
4. rooms of the activity (where do I go?)

1-3 are fairly obvious, and 4 is, too, at least in my experience. the blocks are currently indicated on the left in the current design (copied from Google Calendar), but there's an urge to make a distinction between the (unchangable) block letter and the (changable) currently selected activity, as well as ensure that the activity looks consistent with the activity selection view. the currently selected activity ought to be visually distinct in that way.

however, if it is really distinct, it would make sense to take you to that activity's detail page when clicking on it. but it's more important to be able to enter the select activity view, so that should have a larger click target! thus by contradiction, this is impossible, QED.

BlockFragment (list of activities)

after selecting a block, the activity selection view where you could use tabs to swipe between A block/B block/etc that day. (this would require some fun with the database.) in this case, the header portion at the top would be dedicated to the day itself, but i don't know how that would work out. where is the most important — here or in ScheduleFragment? considering what I wrote about ScheduleFragment, I'll say the latter for now; BlockFragment should be solely a list for changing activities. so no fancy material headers, i suppose. aw.

here, the activities needs to be concise: even displaying only activity names, iodine's list is still long. currently it's just the name and description. that is the real challenge here: there's a lot of information that demands to be known simultaneously:

1. the activity's name,
2. if it's favorited,
3. if it's cancelled or restricted (can i sign up for it?),
4. its remaining capacity (will anyone else be there?),
5. if it is currently selected (not done by iodine).

actually, if the API is fixed (#8), restricted and cancelled activities should probably be hidden by default, because there's no point wasting space on an activity you can't sign up for.

presenting the favorites in a prominent way is also important, because they are the most likely to be selected. one way is to show them at the top of the list, but then they should be displayed twice, which is complicated. the Lollipop contacts app has its own tab for favorites, but if we use tabs for each block, that clearly won't fly.

the contacts app also has letters to the left of the list for alphabetical sorting, which is great (and i've made a feeble attempt to copy that). but then that space can't be used for other things — indicating if an activity is currently selected or favorited, or its capacity. real estate is precious: only a few vertical pixels for all this info.

ActvInstanceFragment (?) (activity detail)

when clicking on the activity a more detailed view should pop up with rooms, sponsors, etc.: maybe a bottom sheet or a full-screen dialog sort of thing. expanding the list item as in iodine is pretty much out of the question... but here, there isn't as much that must be packed in; so not as much careful thought is necessary. lots and lots of space, comparatively.

but here we again run into the problem of distinguishing: where is the distinction between an EighthActv and EighthActvInstance, and how should it be represented? is it even important? perhaps not; a search for the name of an activity will probably be more useful than listing by AID. which brings me into questioning the reason for this distinction in the database, especially given the API design, but that's for another time, i think i've been writing this for an hour or something o.o.