[Feature] add new journal entry from the view entry screen

[rogercreagh]

Is your feature request related to a problem? Please describe. After creating a new journal entry you are returned to the view entry screen, which is sensible as you probably want to check your entry before returning to the list.

However quite often the next thing you want to do is to create another new entry. There is no quick way to do this - you have to return to the list first.

Describe the solution you'd like A button (preferably) at the bottom of screen to create a new entry. Either with the copy (which I have never used and could well be removed or buried in a menu), trash (seldom used) and request sync (frequently used as auto sync is not reliable) icons, or another floating button like the edit item one.

Describe alternatives you've considered Add it to the three dots menu in the top bar - but this would be pretty poor solution as youd never see it that being a placecwhere very rarely used items are buried.

Create new item from the view item screen is (for me) a frequently required function and should a clearly visible option.

Additional context

As well as creating a new entry right after creating a previous one, quite often I want to check a previous entry before adding a new one - again a shortcut to get from item view to new item would be very useful

Your current device and version

• Device: tablets and phones various
• Android version: various from 10 onwards
• jtx Board version: [e.g. 2.7.5/6
• Downloaded from: github and fdroid

[patrickunterwegs]

Hi @rogercreagh , thanks, indeed I have been thinking about a refactoring of the details screen. While I would like to keep the functionality and elements, I would like to get rid of the edit screen and allow viewing and editing on one screen. In the course of this I would like to get rid of the bottom app bar and only keep the floating action button. As the switch from edit to view mode then doesn't exist anymore, the space would be free for a floating action button to add a new entry.

In the course of this refactoring I would also like to tackle the problem with autosaving that you have. The reason is still not obvious, but I have an idea how to prevent this.

[rogercreagh]

Hmm,sounds possible.

So with a unified view/edit screen would the [New Item] floating button save or discard any changes to the existing item? That needs thinking about and trying.

As soon as there is a test version I'll try it on the tablet which uses GitHub releases and comment.

I do think that with a unified View/Edit screen you are also going to need at least a discard changes button. There are four essential actions needed:

1. Save any changes and return to the list
2. Discard any changes and return to the list (very important as it is easy to accidentally make unwanted changes)
3. Save any changes and start new item
4. Discard any changes and start new item

Discarding changes needs to happen irrespective of any autosaves or syncs that may have happened while on the view/edit screen.

Personally I dislike autosaves on all systems as you are never sure whether it has saved or not or how to undo your changes if you want to revert - google docs for example is a nightmare because of this, although tolerable because of the benefit of shared/collaborative editing.

Its difficult to see how you could map the four functions onto only 2 buttons without having each pop up an extra dialogue.

My preference is four or five buttons - plain [Save] so you don't loose your work, [Undo] which reverts all changes since the last manual Save or exist, [Save & Close], [Save & New], and plain [Close] which exits without saving. That puts me (the user) in control and doesn't attempt to second-guess what I might want to do.

I'm a bit sceptical about a unified screen, as editing and viewing are two very different modes. For example when viewing you don't need to show empty fields (eg Categories, etc) and if they are shown they can be much simpler and take less space than with the dropdowns etc for selecting values.

A typical medium length entry item fits on a tablet screen fine in view mode, but in edit mode you have to scroll to get to all the fields - you can't see it all at once. Hence 2 separate views are needed.

[patrickunterwegs]

Thanks @rogercreagh and sorry for the late reply. I had some more thoughts about it and tried around a bit. For most textfields it just makes sense to just tap on it and edit it without changing the whole screen.

When it comes to the five options that you mentioned for the floating action button ( [Save], [Undo], [Save & Close], [Save & New], [Close]) I already don't like it in the quick add dialog on the list screen. What I would consider is to save the changes immediately, but when autosave is not enabled, to show a dialog that asks the user if changes should be kept or reverted to the original once the screen is left (this could happen when the user pushes the back button, when the floating action button is clicked to add a new one). Additionally I'd add the option in the menu to revert the entry to the original before editing was started.

When it comes to editing categories, resources, attendees, I'm considering putting the editing capabilities into a dialog, but I'm not sure yet...

It's a lot of work though, so I'd like to be rather sure that I want to release that change after all. So if you have any other second thoughts, please let me know 😉