Colouring of field values in pull-down menus

[ocrasborn]

Users find the list of choices for the phonological fields daunting. Rightly so, sign languages are simply complex (no pun intended). But there's more prominent or default values in each list of field values, and less frequent ones. We can sort them in a certain way of course, but I was wondering whether it'd be realistic to use different colours to visually group field values, making the frequent / default values red, say, the secondary options green, and leave the exceptions black on grey, say. Could somebody dig into that? If possible, we could let admins specify this in the admin for each field value.

[susanodd]

I'm working on a mock-up, just using a settings table on my local server rather than something in the database.

[susanodd]

As an example, using the frequency view, the addition of colors looks like this. (Below this is based on the frequency of the choice across all datasets: Red if > 500, Blue if > 200, Green if > 100 otherwise or if empty Black.)

[susanodd]

Here's another variant with colored cells. The colors are based on the frequency of the choice. This is again on the Frequency page. It already shows the lists of field choices so it's easy to see what colors would look like.

[ocrasborn]

Hi @susanodd , a bit of miscommunication here, I'm afraid: we don't need any colouring in, say, frequencies or minimal pairs or list views, but only in the selection of a value when describing a sign in the detail view using pull-down menus. It's the selection of a value from a 10+ value list that is difficult for people. Sorry if I wasn't clear enough!

[susanodd]

@ocrasborn do you want the colors dependent on frequency of the choices? Or just admin-assigned?

I intended the above to show what adding colors to the choices may look like, with two styles.

Can color assignment be done on say the Manage Field Choices page for a dataset manager? All the field choices are visible there, too.

[I'm trying to show this so far by using a static table rather than modifying the database. That's why I used the frequencies to determine the color since that can be generated.]

[susanodd]

Here is an example with a color selection (white, red, green, blue) column for each field choice. For this example, it sets the color selected in the color column, as well as sets the column where the field name appears.

The display is a bit primitive. The code does nothing except change colors of the display.

[ocrasborn]

The colours should be admin-assigned, yes, and not automatically assigned based on frequencies or something else. The admin interface looks just fine. I'd suggest letting admins paste in hex values to pick the colours, so that we can be fully flexible there. As we won't do this regularly, there's no need to make it user-friendly by using the standard mac colour picker interface or something, just a text field for inputting the six characters/digits would be fine.

[susanodd]

@ocrasborn, would you like field choice colors to be per dataset?

So far, I'm working on it that they are independent of the datasets. I ended up making a separate page rather than including the code as shown above. The current setup of excluding field choices is implemented as a "set". This means that updates are also done as a "set" of choices to exclude. This information (excluded choices) is stored as a set in the Dataset model.

Because field choices otherwise are not part of datasets, it's not possible to update colors in the same template. (The colors can't be set per each dataset.) However, if you would like this functionality, I can implement it in a different way. This could either be by allowing a dataset manager to set some colors (say colors for categories of field choices). And then put the fields into those categories. That would be analogous to how exclusion is done. The colors would then be stored for the dataset and fields in those sets.

At the moment, I put a field_color in the FieldChoice model. That makes it easy to display because it's available in a field choice object.

I guess it depends on how you want to think about colors, as just something relevant to field choices, to assist in selection. Or as some kind of dataset specific display feature.

There is also a possibility to introduce some kind of Color feature (model) and as for relation objects, link field choices to colors.

[ocrasborn]

Hi @susanodd : No, they should be independent of datasets, to be specified with the field values in the admin. Is it possible though to begin with to colour-code specific items in a pull-down menu in the interface? I thought that would be the biggest issue to solve.

[susanodd]

Yes, that's the idea. I'm working on where the colors will be stored. (I did the first version just doing stuff on the page, then it all disappears, it needs to be stored in the database, of course.) (That was the intention of the first example, to show what colors look like in lists of field choices.)

The things in the pull-down lists (of Phonology, etc) are field choices. So the color for each thing in a list can be retrieved (as desired) when the list is displayed. (From a stored color in the field choice object.)

The colors once set can be shown on items in the pull-down lists. I've been doing it in the Field Choice page because the layout is user friendly and organized.

The idea is then that the colors you set there will be shown in the gloss detail view.

I did a global setting for showing colors.

I have the page for setting colors working more or less. I'll work on showing them in the pull-down lists of Detail view next.

I did work on that already, until I got frustrated with poor choices of colors making it impossible to read the text. That's the idea of the field choice color management page (based on above view), so the user can see how the colors look on the text.

[ocrasborn]

Just to be clear: we don't need or want very bright and contrastive colours necessarily, just a slight change in hue with respect to the default grey background would already single out certain options. Plus we won't be setting more than two different colours I expect (in addition to the default, of course) in any menu. What I expect is that for Location, we will single out Neutral Space with one colour (since it's so frequent), and then the major body locations with another. For handshape and orientation, we would highlight with a colour the most basic values, so that the complex values will move out of focus for the user. I'm so looking forward to all of this! It will really add to the usability of the system and to the systematicy in coding data.

[susanodd]

here are some screenshots of a field choice color management page. I added a preview pull-down list. Excuses for the color choices shown!

The color picker comes from Django, because the input type is color and the field is type color. There's a separate scroll bar in each panel of the category, the right panel where you can set the color,, and the left preview panel in the list. The panels can scroll separately. After setting the color the colors displayed are revised. (The last screenshot shows the list also open. My cursor was on top of something and caused a hint to show.)

[To do: make it so after setting the color of a field choice, its category stays open. At the moment all the categories collapse after revision of a color.]

[ocrasborn]

This looks great @susanodd ! Is the colour picker I see in the screen shot the standard Linux one, and would on my mac the standard Mac colour picker be used?

[ocrasborn]

Oh, one request for when you're almost ready with this: to make it only available to admin users (like me :-)). A menu time for it would be nice though, although I'm not sure where it would best fir really, we don't have a 'Settings' menu (yet!).

[Woseseltops]

Nice work @susanodd . Now you're making mockups, maybe also one for how it will look for the end users? I guess this dropdown, now all red, will get different colors, right?

[susanodd]

Yes, it should be the browsers own color picker.

I'll see about making a mock-up for the Gloss detail view. I say mock-up, but it's actually working. But only that one management page actually does anything.

And I'll do a Settings menu if it's a superuser, to restrict access.

[susanodd]

Here is what it's looking like so far, showing the colors in the Gloss Detail View. First the Managing page to show the set colors for Location, then the Gloss Detail View showing Location with those colors set.

All the red in the Edit mode of Gloss Detail View maybe needs to be less red? It's a bit red.

I'm still working on getting the fields to update with the colorful interface. The Manage page works for updating the colors. But the Gloss Detail needs a bit more work.

[ocrasborn]

Great @susanodd !! Now I see this, I realise I hadn't made this explicit, but it'd be fine to just show the colours in the pull-down menu in the detail view, and that once a coloured value is selected and confirmed (by clicking OK), the colour need not display.

[susanodd]

This is nearly done. I'm keeping it separate from the other pages, so it is a page for superusers to set colors in a Settings menu, and a preview page for Gloss Detail View.

I've got a bit stuck getting this to work together with the "key navigation" Gloss Detail View code. (The vertical navigation within the individual menus isn't working anymore.)

And I'm still trying to get the pull-down menus to look similar to how they look normally.

I'm keeping the two new pages separate in a new menu, with the revised javascript code only for these pages so as to avoid side effects on the rest of the code.

[susanodd]

[susanodd]

Oh, I should explain. I got the update part working. Previously (in the previous screenshot), only the display of colors in the Gloss Detail View was working. Now updating the fields also works.

[susanodd]

This branch is caught up with the master branch now, @vanlummelhuizen, @Woseseltops

[susanodd]

There are two pages in the Settings menu (not on the live server) The intention is that superusers can set field choice colors and preview them. The "update colors" is done here (crazy colors on my machine):

[susanodd]

Previewing is done via a new minimal search page, where the results link to a gloss preview template with colors in the pulldowns. Otherwise it was not possible to keep the colors separate from the rest of Signbank. I implemented it this way to avoid side effects to other code. Also the gloss preview template lets you do updates, like normal. The colors search page is in the settings menu as show:

[ocrasborn]

Looking great, @susanodd ! I'll be (when it's live) so happy with this!

[susanodd]

Shows sorting on local server:

[ocrasborn]

Hi @susanodd , I don't see the settings menu yet on the live server, should I? In the admin, under Pages, there's no page /Settings/ yet.

[vanlummelhuizen]

@ocrasborn I think @susanodd and I added the menu items at the same time. Please check them out.

[susanodd]

Yes, I noticed that too!

[vanlummelhuizen]

@susanodd I fixed the ordering in the dropdown menus. See https://github.com/Signbank/Global-signbank/commit/868dba8aa2815f4c75f27ed966d388a4c957a30c (on master, let's call it a hotfix). You transfered OrderedDict data into a normal dict. Why is worked on our local servers, I don't know. Perhaps a Python version thing.

[susanodd]

Great! Thanks!

[vanlummelhuizen]

@susanodd I found out that it has to do with the fact that on the live server, Python 3.5 is used while I think you use at leas 3.6. Apparently, in 3.6 the insertion order is retained in a normal dict. See e.g. https://stackoverflow.com/questions/39980323/are-dictionaries-ordered-in-python-3-6

[ocrasborn]

Hi both (@susanodd , @vanlummelhuizen ), here's my first findings:

• Browser issues on Mac (not disturbing, I'm happy to adapt, we don't set or change the colours too often): On chrome, I just get an empty page with grey dividing lines, but the row content doesn't appear; in Safari, which I normally use, I don't see the box to click to pop up the colour picker, but when I click in the area where it's supposed to appear, a colour picker pops up (not the default mac panel in a separate window but a nice table with many options, with the option to open the standard colour picker); in Firefox, all seems good.
• Setting colours (in Firefox) works fine.
• But then I see no effect outside this new Manage page. Not on the other new page, Preview, and not in the menus when editing a sign (where it's most helpful), and not in searching for phonology (where it's second most helpful)

[susanodd]

@ocrasborn, I just tried it on my Safari browser (See below).

The colors you set are visible in the dictionary/gloss_preview/NNN page. To get to such a preview page (with colors in the Gloss Detail Preview) you use the Search page under Settings, which has links to Preview pages. The search page is an abbreviated search, for convenience.

It was designed this way to keep the Manage Colors and Gloss Preview pages separate from the rest of Signbank, as this is developed.

[susanodd]

I will work on adding colors to the query formulation part.

[susanodd]

The Gloss Detail View shown above is at /dictionary/gloss_preview/4483

The Search page under Settings is to make it easier to get to preview pages and keep them separate. Updating glosses on this Edit pages works as normal. I did it this way so the addition of colors can be experimented with.

[ocrasborn]

Three comments/questions:

1. @susanodd wrote: "I will work on adding colors to the query formulation part." Oh, I see, so that has yet to be implemented? Is that what you mean?
2. @susanodd wrote: "The Gloss Detail View shown above is at /dictionary/gloss_preview/4483". Ah, I see. That's good, that I can experiment with how it looks, but then when do I pass on the finished settings to the rest of the system, so that all users will see it everywhere? Is that also something that has yet to be implemented?
3. The revision of the drop-down menus has broken the keyboard navigation it seems. A student already noticed this when navigating the strong hand/weak hand drop-down under phonology. When you press a letter (like S or M) to jump to the right value, the menu sometimes (?!) changes to a long list of values in a text string, the drop-down disappearing. I tried this under a regular sign somewhere (not in the settings page I mean), and the first time this happened like for the student, but then I couldn't make it appear again. See screen shot the student sent me.

[ocrasborn]

Oh, and here's what happened with the test sign in the link above, after I first managed to replicate the above disappearance of the menu, and then turned off the edit mode: ![Uploading Screenshot 2021-02-12 at 11.42.13.png…]()

[susanodd]

Yykes! Point 3, the navigation has only been to use "return" to go to the next field. I haven't added any other navigation characters. (That would apply to both the normal Gloss Detail View and the Preview. Both have only been set up to use "return" to "not do anything to the current field".) (I just checked. I see this is not working on the WD WP fields on the live server.)

I'll look into the horrible red code! It looks like it hasn't been reset after stopping with editing.

The Preview page uses totally different java scripts to prevent side effects in the normal page. (The normal page has not been edited for colors.)

Point 1, I didn't know this was to be implemented. I focused on adding colors to the pull-down menu's in Gloss Detail View. (And functionality to set colors and navigate to the --preview-- gloss edit page.) Point 1 requires modification of the Select 2 java script.

Point 2, when the Preview page is working entirely as expected, it should be straightforward, just use the Preview page instead of the Gloss Detail page. Yes, this has to be done later.There is a lot of java script to modify the appearance of the menus. I also had to modify how the data is passed to the database for updates. (The ajax parameters are set up in the new java script.)

Regarding the red text, I will check this on the normal Gloss Detail code. There was something I had to change with the Weak prop and Weak drop in the Preview. Those fields are Booleans, but we use three value logic in the case of Neutral. There are some glitches converting between these formats and at the same time making them human readable in various languages.

The red text above looks like something related to the ">" characters. That has been addressed in a different issue, but maybe it's broken again.

@vanlummelhuizen discovered that we are using Python 3.6+ on our local servers, but the Global server is using Python 3.5. That was the cause of the sorting dilemma.

[susanodd]

Okay, I repeated the red text error. It's as you wrote. Edit the gloss, edit the Weak hand, click "S", the editing stops, but there is that awful red text. That's my fault. I didn't remember you could use "S" to stop editing. But @Woseseltops added that long ago.

[susanodd]

I see that the key presses as described in the template (code) are: "p" : phonology "m": morphology "s": semantics

Are these the intended uses of the key press abbreviations, or are users using keys to navigate within lists?

When I typed "s" the editing stopped. But that doesn't match the above. The abbreviations above predate the "navigation to the next field".

[ocrasborn]

OK, let's create separate issues for what has yet to be implemented, as the configuration (aside from the above menu issue) is working well. I'll set up the issues, but do add info as you see fit, @susanodd

[ocrasborn]

Hm, well, as I remember it, whenever a menu was opened (or perhaps even already when it was selected), it was possible to type a character and the selection would move to the first item in the list starting with that character. Wasn't that one aspect of #140 ?

[susanodd]

The lookahead's work that way. When you start typing a gloss or lemma, it shows the matches for you to select from. That's implemented as ajax calls to the database.

I can't recall whether the normal choice menu's worked like this. This could be a browser feature. I suppose it could be implemented for field choices in a similar way. But a characteristic of the gloss/lemma type-aheads is that nothing shows until you type a letter.

[susanodd]

Okay, I tried the normal Gloss Detail View and it works to type a first letter.

TO DO for the Gloss Detail Preview.

However, S still kicks it out of Edit and goed to Semantics (in normal Gloss Detail).

[ocrasborn]

@susanodd , I'd be happy dropping the keyboard navigation for jumping from panel (phonology) to panel (semantics; for instance), as well as dropping the S for disabling Edit mode.

[susanodd]

I've got it working now so that a key press scrolls the pull-down to that letter, if found.

[susanodd]

I've got the scroll also working inside the pull-downs so it scrolls to the selected element when you open the list.

[Woseseltops]

Hey @susanodd , great work in this issue. I reviewed the code. My questions:

• I noticed that you edited external dependency jquery.jeditable.mini_colors.js a bit... do you think it would also be possible to achieve what we want without editing external stuff? (not a rhetoric question)
• In forms.py there still are quite a number of commented print statement... do we still need them?
• Same for console.log in field_choice_colors.js

[susanodd]

The jeditable is a bit different. It's been using a signbank javascript for quite a while, not the external one. The code had to be different because of ajax calls. Also, the way the colors work with that needed to be modified as well. The new _colors file is only used in the new pages that use colors, to keep the rest of the site the same.