entry number for display and navigation

[megahirt]

The current controls for navigating the list make it difficult to know exactly how far down a word is the dictionary list.

The list scrollbar does not accurately depict how far down one is in the dictionary (progress) and continues to jump as you scroll down to the bottom, because it is loading more items into the list.

There are previous/next buttons for navigation, but it's not clear what entry number you are on when you navigate back and forth through entries.

In summary, this issue describes a new feature to display the entry number which also acts as a "go to" entry input. The proposal is to add an input in-between the prev/next buttons and display the current entry number. The user may also type in a number, which when navigating away or pressing enter, that number of entry is displayed.

Mockup:

Requirements:

• Should display the current entry's index number (1-based)
• Should be editable
• Should protect against invalid input, including numbers out of range (revert to current entry number)
• Upon user typing valid entry number, should navigate to that entry
• For desktop only. There probably isn't enough room for an input on mobile.

[rmunn]

Another related idea is knowing how many entries are in the filtered list vs how many total entries there are. If there's a filter active, the "Next" and "Previous" buttons should go to the next or previous entry in the filtered list, not in the total list. So if the filter is word field includes the text "house", then clicking Next from the entry "housewarming" should jump straight to "lighthouse" rather than going to the next alphabetical entry ("hover", for example). And the entry number should jump from 1,004 straight to 1,216 when you go from "housewarming" to "lighthouse".

Might also want to have a second entry number when there's a filtered list. E.g., housewarming is entry 1,004 and is also "number 5 out of 27 entries that match current filter". (However we'd phrase that in the UI).

[rmunn]

And another related idea would be to track some sort of "doneness" alongside unreadness, possibly with a flag the user can set, and display how many entries are done vs how many are marked as being in need of work. For example, the project manager might want to tag a certain number of entries as being in need of revision with the language team. Then when the language team meets, they could filter the entire list by "Entry status: Needs Work". As they move through each entry, they could click on a button or checkbox for "this is done", and that entry would be auto-flagged as "Entry status: Completed" and they would move on to the next one, with a progress marker saying "37 out of 120 entries completed".

Finally, when they finished all 120 out of 120 entries, there could be a bulk-edit feature that would remove the Completed status from all of them and send their status back to "empty", because that way next time the user marks off 10 entries to be worked on, they would see "0/10 complete" instead of "120/130 complete".

[alex-larkin]

@rmunn, in regards to your last comment, that idea reminds me of the custom color tagging in #1008. I lean towards going that route, because I think it can do what you're describing here, while also giving more flexibility to the user.

[alex-larkin]

If the intent for adding an entry number field is for users to be able to toggle easily between a small set of entries, I wonder if it would be more intuitive (and easier) would be for users to have access to a list of recently viewed entries (perhaps the last 10?). This way they would just click on the word that they want. They won't have to remember which number goes with which word, and type it in. As entries are created, deleted, and edited, an entry's entry number will change. That could also be confusing.

Wordreference.com has a feature like this:

And see my next comment to see how they implement it on mobile.

[alex-larkin]

This is how WordReference gives users quick access to their recently viewed entries on mobile. It does require a few taps, but I feel like it's a good tradeoff, given how often the feature will be used (probably less often on mobile).

Screen_Recording_20210902-092243_WordReference.mp4

[megahirt]

After a conversation with @alex-larkin he doesn't see the need for this feature because he and others like him are not using Language Forge in a linear way to do a dictionary cleanup tasks. Some people like Margarete are doing dictionary cleanup and need a way to navigate to a specific place in the list.

I'm tabling this feature for now, however I think it will be important to implement at some point. It could perhaps be implemented under a "navigate" sub-menu.

[longrunningprocess]

fwiw, the scrollbar starting at the top rather than mapping to the "current" word might be a quick scrollTo fix and potentially a separate issue/bug from all the feature discussion here.

[alex-larkin]

Ah okay, are you just saying we should pull that out into a different issue?

[longrunningprocess]

potentially, just offering that as a possibility but it's something we could discuss at our next stand-up.

[alex-larkin]

Ok. I also just created #1129 to separate out the "recently viewed entries list" idea into it's own issue.

[longrunningprocess]

I went and added it to the Backlog as well.

[rmunn]

Just had an emphatic request for this feature from a user who would greatly benefit from it. I'm going to put it on the September project board and we can prioritize it at our next meeting.

[rmunn]

During standup today, we discussed how the code loads the entries into IndexedDB as they come from the server, so that they're available offline. The function that does this is loadEditorData in src/angular-app/bellows/core/offline/editor-data.service.ts, and the refreshEditorData function below that is also worth reading to get an understanding of how this happens. Those functions populate the entries list in the EditorDataService. You can see it in use in src/angular-app/languageforge/lexicon/editor/editor.component.ts where EditorDataService is pulled in as a constructor parameter, and then there's a line in the class definition (which turns into a line in the constructor once Typescript is compiled into Javascript) saying entries = this.editorService.entries.

It's a lot of code to read through, but once you're done reading through all that code, you'll come away with a better understanding of the data flow.

[megahirt]

Hi @palmtreefrb , as @rmunn said, you'll want to take a look at the EditorDataService, specifically the two arrays entries and visibleEntries.

entries contains all entries loaded into memory, whereas visibleEntries is an array of only those entries visible in the list container.

Additionally, there is a method getIndexInList() that will figure out what the index is given an entry id.

I hope this helps you get farther on this card - thanks for your hard work!

[palmtreefrb]

Just tested in QA and it looks good,

[megahirt]

Tested on QA and it looks good to me as well.