Change the structure of preferences

Issue #79 resolved
Peeter Tinits created an issue

This is more of an idea. If we are going for minority languages, whose users don't have to have expertise in computers or wikipedia, the preferences could also be designed to be understood best by the first time user who does not know either computers or wikipedia. This would entail changing the logic behind it a bit.

It seems to me that the main function of the programme for people who don't know how to use computer programs well is to translate simple articles between some languages.

Things like "category depth" and "filters" do not seem like basic features for this, however the languages chosen do seem basic.

I would make the first page of preferences include: 1) Interface language 2) Languages used

Then as a subtopic: Display 1) Font size 2) Display text horizontally or vertically (would be nice to have an illustrative picture there) 3) Filters (also explain it on the page) "In source texts I want to see" * More than just the introduction * Images attached to the article * References in the article * Wiki-specific templates

And instead of corpus (users don't have to know what it is) use "Language skills"

Also "Adding articles" (or something related to the activity where they are relevant. 1) Category depth (this really isn't basic) 2) maybe something about suggestion lists or so.

Perhaps all the rest could be under a separate heading of "advanced" or smth.

Also: It doesn't hurt to explain both Content assist and Text processing also within the preferences with 1-2 sentences. Some people probably won't click otherwise.

Maybe also make "lookup", "find/replace" and "snippets" optional and turned off initially in the interface, as they seem also to be some more for the advanced users?

I don't want to make very radical changes, and these tech features are also very useful, but I think we should still keep in mind a new and inexperienced user with some free time and language skills (but not skills in computers or wikipedia) as the main target audience. The current interface looks a bit daunting and cluttered maybe for them. However, if the extra abilities were optional, it would make it much better for them I think.

Comments (23)

  1. Peeter Tinits reporter

    The preferences menu could use another look generally. The main aim I would go for would be transparency to a newcomer and not conciseness of form. Thus I would avoid terms like GUI as the main target group may not know what it is, and explain the filters instead of just mentioning them.

    I'd say the structure of the menu could use a slight makeover generally in regrouping the menu items in functional terms, - this is probably difficult to do over bitbucket, and perhaps best done on a physical meeting. Or at least in a chat interface.

  2. Peeter Tinits reporter

    This is best done with pen and paper. I can translate the suggestions into an ideal setup.

  3. Peeter Tinits reporter

    Ideal menu:

    • Main (incl. Interface language + Languages used + adaptation)
      • Language skills (as is)
      • Data collected (contents first specifyied on startup; on top explanation of data on wikipedia - how it is public anyway; then ticks: tick1 collect metadata for corpus?; tick2 collect usage data to improve software)
    • Display (incl. font size + horizontally/vertically + filters)
    • Adding articles (incl. category depth + perhaps something about suggestion lists)
    • Advanced
      • Text processing
      • Content Assist
      • Dictionary look-up
  4. Andrjus Frantskjavitsius repo owner
    • Translation (languages, skills, adaptation, data sending)
    • Display (size, interface language)
    • Content assist
      • Inserts
      • Collect
      • Symbols
    • Pull
      • Templates
      • Replace
    • Lookup
  5. Peeter Tinits reporter

    Can you fit all that on the first page, or are the () brackets submenus? If it fits then awesome.

  6. Peeter Tinits reporter

    Great idea to combine the display and skill level! I assume, it just scrolls if you add 10 languages? But now I'm starting to worry if skill level fits the names....

    I would move the corpus tick to another subpage (so as to include explanation + link for people to read whenever they have time. Also this doesn't seem likely to be changed frequently). And would add small instructions on the top of translation. "You can add languages with their native name below. Skill level follows the wikipedia language skills structure described here: [link]". What do you think? Would that seem ok?

    Possibly in the future we could include "Publish the language data on my userpage" button there too.

    Top would then be

    • Translation (clarification+link, adaptation, languages box)
      • Data (clarification+link, tick box)
    • Display
    • etc

    Thanks a lot!

  7. Peeter Tinits reporter

    But would like to hear @keeleleek 's opinion on this too. It doesn't necessarily have to be compact, it just has to be visible/findable.

  8. Andrjus Frantskjavitsius repo owner

    It's a scroll pane so, yes, it will become scrollable.

    Explanation can be moved under the tooltip. Creating those preferences pages is tedious and time consuming. If there is another option, then I would go with that.

    Also, since the data sending is enabled by default, I don't think it's that important to make it 125% clear.

  9. Kristian K

    I prefer Andrjuses version pictured and to have the tick on the same page.

    @peeter_t2 since we are not using the same language explanation as Babel is doing, we can't assume good faith in letting our users publish their language skills using the Babel template on their userpage.

  10. Andrjus Frantskjavitsius repo owner

    Screenshot_2016-01-09_15-42-05.png

    Content sisaldab Category Depth väärtust.

    Pulling ja Spelling on laetud pluginate nimekiri.

  11. Peeter Tinits reporter

    Yes, creating the menus is insanely time-consuming and tedious with just text over the internet.

    The problem with tooltips is that you can't put a link in there. We currently have short paragraph explanations on a few prefererences items+link - it looks really nice.

    I'll write down my thought on the first menu, including the help texts by Sunday evening.

  12. Andrjus Frantskjavitsius repo owner

    Well, one can't add links in labels either. I can add a link below the check box.

  13. Peeter Tinits reporter

    I think what used to be within "language corpus" submenu is exactly the kind of info we could include in many options. Both language and data collection ones could use a link + explanation before the link. As it would take up space, I would put the tick box into a submenu - it creates no problems for the main page.

  14. Peeter Tinits reporter

    The main principle that I am following is that the design should be made for a newcomer user and not an experienced user. The experienced user can manage anyway. That's why I think we should go through the trouble of explaining things in some detail, if we can make the space. To follow from this the interface does not have to be compact and pretty, but it has to be informative and do all the tricks.

    It's possible that my ideas are actually not good with that principle, but are we agreed in that principle at all?

  15. Andrjus Frantskjavitsius repo owner

    I will add the link but the Translate page will remain the same.

    The positioning is perfect. The page not only lets the user select languages, but it also encourages to set proficiencies, while explaining/hinting to why the data is being collected and why proficiencies are needed.

    If data collection is under a different page, then the user might not understand why he/she needs to set proficiencies.

  16. Peeter Tinits reporter

    Ok, let's do that then. I'll include some info on language skills on the corpus link on the wiki page, and that will be enough.

    Solved, as far as I'm concerned. :)

  17. Kristian K

    Just one comment about the Filters in the last screenshot. Isn't it possible to create more filters? And if more are created, are they populated automatically on the preferences screen? If done automatically, maybe it would be better to show it as a list instead? I think users would then more intuitively understand that filters is a thing that can be modified.

  18. Log in to comment