-
Notifications
You must be signed in to change notification settings - Fork 187
Discussion Book Details View
I am wondering if there may be a place for a 'book details' view much like the editing view, but which merely displays the book. The things that made me consider this were:
- in the 'Edit Book' window it would be nice to use 'back' and 'forward' (left/right) gestures to go to the next book (without editing the book details and clicking 'save' or 'cancel').
- it would be great to scan an ISBN and go to the 'book details' screen (if present)
Once on the 'book details' screen, I would envisage the 'Menu' button should bring up a menu with the following functions:
- edit book (go to traditional editor)
- lend/return book
- delete book
Not sure what other functions would be useful. Any atomic operation on a book would be a candidat - eg. changing the cover, changing the rating, marking as 'Read'/'Not Read' etc.
In any case, I'd be interested in thoughts (especially those of the original author!)
I like the idea. Maybe add a new tab (at the beginning of the tabs) which contains this information. You could also maybe replace the "Your Comments" tab with this details view and have the "comments" fields underneath.
I was thinking this might end up geing a whole actiity, or perhaps a different view of the bookCatalogue; selecting 'edit' would go to the bookEdit activity.
If it was part of the bookEdit dialog, then the 'Save' and 'Cancel' buttons become confusing. It might be possible (I don't know enough about Android) to have two alternative views in the bookEdit dialog.
Any thoughts/guidance here?
It would definitely have to be a separate activity. Each tab under BookEdit is it's own activity.
Also the save and cancel buttons are only part of the edit tab. e.g. the loan and anthology tabs do not have those buttons
Ah....ok...
My reading so far led me to believe that an Activity corresponded to a root UI element; I did not realize a tab inside a dialog could be a separate activity, but it makes sense when I give it some thought.
Tab sounds fine, but I am not sure how it will interact with the editable tabs. What I am wondering about is:
User goes to view tab moves to edit tab and changes something moves back to view tab and uses a gesture to go to 'next' book I think this will lose their changes OR leave the tabs out of sync.
To rectify this postentia problem, it seems we would need to do one of:
Use a separate view dialog and treat the editor as a popup dialog; you then cant get back to the view dialog without finishing the edit dialog.
Track all field changes and prevent leaving the edit dialog if a field has been changed. Much like the standard 'Document has been changed...' dialogs.
Number 1 is probably my preferred
Number 2 may work, but I am not sure how to track field changes. Any suggestion as to the best way would be good.
You've actually raised a current issue with the software. If you are in the edit tab, make a change and then goto the "your comments" or "loan book" tab it will lose your changes.
I have considered getting rid of the "save" button altogether and automatically saving whenever a field is edited. Though that restricts the ability of undoing a change.
This is a thorny one; I have inadvertanly edited books a few times AND typed stuff (usually by waving my hands around while the app is active)...so at the current time, the 'Save' button has saved me a few times!
That said, if the default tab were the 'View' tab, then the involuntary editing problem would be considerably reduced.
What you mention about the other tabs is interesting; I had noticed lost edits but never really looked fo the cause. I notice that going to the loan tab clears the comments tab and edit tab, but not vice-verca. Is this a problem with the tab container? Is there a simple work-around?
If there is no good work-around, then a slightly modified version of the original idea may be a good solution:
- From bookCatalogue, context menu allows edit/view/loan/delete/comment
- From bookCatalogue, clicking on a book takes you to a view activity (no tabs)
- View panel to have left and right gestures to move through list
- on view panel, the 'Menu' button gives access to edit/loan/delete/comment
- The loan tab becomes a stand-alone sub-activity so that it will not cause loss of edits etc
- the edit and comment tabs either get merged or (somehow) incorporated into a single updateable item (potentially using two tabs still)
The down-side of all this is extra clicks.
Op | Current | As a Tab | As a Dialogue |
---|---|---|---|
Go from list to edit | 1 click or one long click and 1 click | 2 Clicks or one long click and 1 click | 3 clicks or one long click and 1 click |
Go from list to Loan | 2 clicks or one long click and 1 click | 2 Clicks or one long click and 1 click | 3 clicks or one long click and 1 click |
Go from list to Comment | 2 clicks or one long click and 1 click | 2 Clicks or one long click and 1 click | 3 clicks or one long click and 1 click |
The main action that suffers here is 'edit', but we could add an edit button directly onto the view panel to reduce the number of clicks by one.
If we stick with using tabs, then we will need to:
- add a new view tab
- (possibly) merge comments and edit tab into one update
- (somehow) prevent changing tabs from clearing edits.
Any thoughts/suggestions?
It makes me think that a tab-based approach may not be ideal if shifting tabs loses the contents of the