Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Usability No-brainers

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Human-Computer-Interaction - Team (category HCI)

Use this page to build a structured list of usability improvements you would like to propose for version 4.5. It would be beneficial if you notice the target group and reason. Also, this is where suggestions discussed on the HCI mailing list should go.

Example:

  • (@editors) Change "Save" icons to button with the text "Save" (they find a text button faster than a weird icon).


Basic Usability Principles

Consistency

Consistency is a basic usability value. It applies on these levels:

  • With other applications (iconography / menu names / buttons / labels / shortcut keys?)
  • Internally across core _and_ extensions (last point links to ECT)
  • Extension consistency:
    • Same templating
    • Same way of configuration
    • Defaults, that work out-of-the-box
    • Goal: Make usage of extensions as simple as installing them: A single click and it works.
  • Things that are currently intuitive:
    • Page tree (mimics Explorer)
  • Things that are not intuitive:
    • "Save" button for "Create new" (maybe something like a 'Save a copy' button could be integrated too)

Best-practices

Define best-practices (red-line) for developers -ficzel

Benefits:

  • 1. to know you are working in an approved way
  • 2. to takeover a site created with others
  • 3. to collaborate with other developers
  • 4. Easier to make documentation (-kasper)
  • 5. Possibly the standard needed for defining certification! (-kasper)

Examples:

  • typoscript-setup
    • naming conventions
    • usage of constants (when, naming ...)
    • where to keep templates
    • how to split templates in parts ( which granularity )
    • naming of template records
  • extensions
    • coding guideline ( already exist )
    • checklists
    • configuration
  • best-practices to teach as concepts is a requirement!
  • best-practices connected to consistency internally and externally

Complexity

  • "Soundmixer vs. Ipod": Too many alternative ways of doing things in the BE. -bas (But; Maybe expert-users appreciate this? Segmentation? -kasper)
  • Again the key word: target group! "Too many alternative ways of doing things in the BE" (bas) definitely confuse "simple" users such as authors; expert users like myself sometimes appreciate the choice! --> leaving the choice for experts, taking it away for non-experts...? - marion

Visually

  • Design backend to be equally effective with small (1024x768) screen resolutions. -bas (In many cases, I've seen 800x600 still is used by editors in small businesses. -Alex)
  • Increase contrast for 'fieldset bars' in main frame (accessibility issue, see hci: colors in new skin thread)
  • Default content elements visually have a 'special' status in the BE (different icons, positions) for no apparent reason other than legacy. -bas
  • Clicking on the icon of a record does something else than clicking on the label, especially in the page tree. This confuses inexperienced editors. -bas (Throughout BE, clicking on icons brings up menu, clicking on label makes something happen, a la "New->Page after". In my experience this separation doesn't affect learning, click-happy users will always be "confused". -Alex)
  • Page Module: The rigid 4 columns representation should imitate the frontend design in the BE to actually match the real site layout. - bas (Consider T3 documentation and this feature's effect on tutorials and videos. Standardization makes for easier teaching with aides that match any site. -Alex)
  • Page Module: Enable nesting of content elements
  • Faster loading page tree when thousands of pages. -bas
  • Search option in the page tree area so you can quickly find a page based on its title. -bas
  • BE without any frames, a pagetree that is a nested list and has all the AJAX and Drag'n'Drop we can imagine. -scharkow
  • Fewer clicks and page reloads involved generally (AJAX can help) -brockhuus
  • Customizable backend like http://pageflakes.com? (Recommend admins can control this behavior to allow/disable on per-editor basis. i.e., admin sets up a BE interface for editors. Ditto for documentation consistency for 1000's of installations. -Alex)
  • Take out the standard content elements from the core system into extensions. why: if you have to modify the TCA array for some reasons, you have to take care when updating to a new TYPO3 version.


RTE (Editors)

For details on the suggestions listed below please see Usability - RTE.

  • Link management (drag & drop in various flavours)
  • Producing nice html-code without having to code
  • Not strictly RTE related but close to: If in RTE mode, no "bold, recursive, underlined etc.." options *below* the rte (reduction of redundant ways)
  • in full screen edit mode: The content Heading should be present all the time! It´s weired for users that they can´t add a heading in fulltext mode.

Personal start-up screen

(See project "alternative starting page for BE users" / "improved task center") (-Balzer/Kurfuerst)

  • Users meet a page with typical tasks, access to wizards etc when logged in. Like most consumer programs.

Added by Andreas Balzer: a special help system like a dynamic FAQ (detailed: a bot) could be shown too.

Kasper: This sounds like a component in the once-a-month dummy backend user idea of a simple editing interface being task/wizard driven

Configuration (developers)

  • Abstraction layer to deal effectively with ImageMagick/GD differences once and for all. -bas
  • Make it clearer what sort of configuration there is and where it can be modified from
    • Sorts;
      • Global configuration (localconf)
        • system (TYPO3_CONF_VARS)
        • extensions
      • User settings (= User TSconfig)
      • Page tree settings (= Page TSconfig / TypoScript Template Records)
    • Tools:
      • Single module gives access to all types?
      • ALL configuration options fully changable via tool that
        • a) knows and respects semantics and contexts,
        • b) secures validity of value,
        • c) contains full description of options possibly with examples. Kill the references! - they should never be needed anymore (or at least completely auto-generated from the internals of the system for those ).
  • Semantical validation of all configuration (Page/User TSconfig / TypoScript Templates / localconf all alike)
  • TypoScript inline editor with syntax highlighting?
  • User / Page TSconfig having same options (less confusion) (ficzel) (I would say, this is not a problem with a validator / editor knowing context - kasper)
  • Reorder options when hitting Web->Template, while you are on a page with no template, and make them less 'frightening'.
    (see part of hci: see thread)
  • Expand/Collapse mode for whole tempate record
    (see suggestions with screenshots at Usability_bugs#TEMPLATE)
  • Remove "Backend Editor Configuration" from TemplateRecord and/or rename it to "Stylesheet editor configuration"
  • Sort properties alphabetically? Or at least divide them into important/exotic
  • Install Tool using Tabs (See suggestion at Installtooltab)
  • Improvements to the Constant Editor:
    • separate different sections of settings into tabs for better overview
    • provide access to certain properties to non-admins (see constant_editor)
    • have a page-browser for selecting page-ids when the property expects a page-id
    • have a file-browser to choose a file from fileadmin for properties of the type "file" (you currently can only upload a "new" file)
    • more flexible "categories" to group related properties
    • some kind of standardized (and documented!) way to configure global stuff that every extension might need to access
    • an easier-to-write syntax; perhaps YAML would be appropriate? (see www.yaml.org)
    • alternatively, Martin Kutschker suggested that "...it'd be great if installer config options, extension config options and constant would be deinfed via an XML format based on or identical to flexform config"

Improved context sensitive help (Site developers/Editors)

For background, please see Some thoughts on context help

  • add a new field for developer related help; internally it could be devhelp, on the surface: developer's help, shows up as a second icon (question mark) which I can enable through my user setup.
  • a strict division between what is there by default when typo3 ships to you and what a site developer/admin changes for the authors (somehow possible, but how?)
  • 'FE editing' for csh and labels. This way you could get rid of the context field, because you have it in front of your eyes. (impossible to describe the context in a meaningfull way when dealing with such complex forms).
  • Perhaps one could even use the RTE and thus having real markup? You write html, using certain elements and classes and they are then converted into docbook-xml?

Front End Editing

Increased usage of the frontend for editing:

  • Ideally, all backend tasks for an editor can be done in frontend (-brockhuus) (Although this will boost usability a full backend/frontend merge will not happen before 5.0 I'm sure.)

Back End Editing

(-peter luser) Increased usage of the backend for editing:

  • move default content elements (text, text with image,..) into an extension (kasper: certainly a thing for 5.0)
  • make it possible to edit/adapt those standard content elements (by making them template based?)
  • possibility (for developers) to create their own customized content elements for special needs
  • possibility to share/reuse the customized content elements easily (eg: export content element as .t3x)
  • Flexible layout of Web > Page: the same way you can define a HTML template for the frontend, you should be able to define a HTML template for the backend page module - so that the layout of the backend is similar to the frontend view -> easier for editors to find the right place for content

Forms

(-ingmar): The goals I'd propose to strive for are:

  • Nice and comfortable overall feeling when using the form
  • Least possible required clicks
  • No form reloads

And my wishes on the technology side:

  • Instant (AJAX) feedback on evaluation errors
  • Auto draft-saving preventing loss of data on browser crashes
  • Inline adding/editing of 1:n relations (like one product has many prices) without form reloads
  • Possibility to template TCEForms to seamlessly integrate them in Backend and Frontend applications

To achieve those goals, TCEForms has to be completely refactored. (I see a link to the FE form ideas of ECT here. I would like to see their concept implemented, even extended to a whole "wizard framework" (supports usability I believe). Technically, the implementation should be done well enough in objects to be ported directly into v5.0 - then we don't waste time on that one - kasper)

Consider the form layout itself rather than default see article about usuability of label position - http://dev.uxmatters.com/MT/archives/000107.php (matthew)

Wizards / Wizard Builder

(-Rio)

First level: Chain of common BE actions.

For example : a "Create a news" wizard could include those action :

  • Ask the BE User for the storage pid (if they are more than one and he

has access to more than one)

  • Open the storage pid
  • Activate the "Create new object" button for the news section
  • When the user leaves the news editor with the "save and quit" button,

refresh the cache of the pages where the new is published.

Second level: Help to key in new objects

  • Wizard to key in a news
  • Wizard to create a new page+text content
  • Wizard to create a new image galery

(I see a clear link to the vision of enhanced backend forms, refer to the ECT suggestion and ingmars form-idea -kasper)

Boris Podzeit: 1-2-3 process for creating pages with content!

Advanced search tool with saved presets

(-Rio) For example :

  • "Give me all the pages where no cache is activated",
  • "Give me all contents unused or belonging to directory pages",
  • "Give me all pages created last month and not in cache"
  • "Give me all pages containing news" ...

The most useful could be to use the TCA configuration to define :

  • the object/table available to the search tool
  • the fields available to the search tool (and furthermore, we have to

take into accounts the user access rights)

  • a search alias (could be the label of the field in TCE Forms) so that

a BE User could ask using the current labels

  • the operators allowed (<, >, <>, = , ...)

Kasper: This search tool already exists for 90% of what you wish in the Tools > DBint section (there is a t3lib-class for it). I think that concept could be revived. Great idea to let people select presets like "Give me all.." but I suggest those are built by the underlying tool (and some could come bundled with the core of course). However, I'm not sure if this is usability improvement - if so, its for developers and admins.

Misc

  • Show tag-names for FlexForms as title-attributes (maybe for titles of all field types?)
  • Selecting users for FE page access is done by a visual map of user groups instead of 1-dimensional list. (Balzer)
  • Reporting tool (joined sql-queries, cvs export) (-Thurson)
  • Spell-checking included as must as possible with underlined words -brockhuus
  • Maybe introduce "tabs" in working area (right) to change module?
  • Improved clip-board, single concept (normal/#1 merged), drag'n'drop

Backend users

  • User Roles - you can even switch between like workspaces? (stigs suggestion)
    • Includes better default sets of options since it appears hard/time consuming for people to define.
    • Task: Create new user. 1) Select "template user" from: Novice/Intermediate/Expert, 2)...
  • Customizing backend for users should be MUCH easier: This is what costs time (and doesn't get done for that reason). 1-2-3 Wizard for that? (-wolters)
    • Backend can be customized to be user friendly! But far too many doesn't go through the trouble doing that; therefore we need better defaults or easier ways to configure backend for various user levels (just a thought: those who actually did go through this trouble must possess important knowledge about how such a backend looks! Who are those experts?? - kasper)

      I have actually customized the BE for different kinds of users / user levels and I must agree: it is far too difficult. Although many options can be chosen by clicking on icons or words, there are too many cases for which you have to dig deep into TS. There is still much I have not been able to include into particular customizations - and I am sure these things could be done... (-marion)

    • (JoH:) More options for configuring backend: From a full scale backend to simply entry-level backend.

Changing defaults

(See "devilish details" thread and Devilish_Details wiki entries)

Core Output

  • no page targets like PAGE_TARGET = xy by default, because frames are out
  • no blurlink() by default, not even in menues
  • set config.inlineStyle2TempFile = 1 by default (done in Typo3 4.0)
  • set config.removeDefaultJS = external (done in Typo3 4.0) (be aware of bug 14314 and bug 16399)

Extensions' output

  • No wrapper div of extensions by default, at least it should be moved from the php code into the extension's ts (disputable, see suggestions in Devilish_Details#EXTENSIONS)

Things that already make TYPO3 rock!

Quoting Irene Höppner: "Removing features should really not be the focus, if we don't want to get rid of one big strength of Typo3." So, let's list what we love about TYPO3 already! This helps to understand the sacred cows better. We don't want to mesh with a good thing, right... ;-)

  • Visual page tree view
  • Extensibility of code
  • Configurable user/group roles
  • Filelist capabilities (upload/manage files, etc)
  • Templating system to configure sites/page-branches/pages as needed
  • Simple ways to create menus dynamically through TS
  • CSS/XHTML compliance support
  • Import/export with T3Ds
  • fe_users
  • per-page and installationwide logging
  • multiple sites in one page tree
  • Nice frameset backend!
  • Page tree is very important concept! (unlike mambo, wikis etc). A good abstraction of the site!
  • RTE is must have: bold, italic, links are top! (Alex)
  • Ability to SU as an editor to see their exact environment as them (and switching back in v4.0)
  • Drill down from left - middle - right works well!
  • Like that the middle-step can be left out; Change sub-module: Right frame changes without invoking another page click.
  • Multilanguage-Support

Scharkows 5

  1. Remove page types completely (except for sysfolders, see #2). Distinguish by page properties (arranged in tabs)
  2. Make a stricter distinction between pages and sysfolders. Enforce, that pages contain content elements, sys folders everything else.
  3. If we follow #2, we can remove the distinction between list and page view: Pages default to page view and sysfolders to list view.
  4. Remove the access module and put it into the page property dialogue (Should we have a "permissions" tab (only relating to BE users) and a "visibility" tab (only for FE stuff like start/stop/hidden/fe-group) or a mix of both (because a lot of users confuse this)?
  5. Remove static templates and all related db tables and columns. They are obsolete and have been since 3.6.

TYPO3 light?

Frits Lyneborg, BEE3 has made this concept which can serve as inspiration to a discussion about a scaled down or special made backend for entry level users: http://www.typo3abc.com/ Frits has given this comment to the link: "I think TYPO3s HCI team should concentrate on creating 2 interfaces; A power-nerd interface appealing to the nerds and a power-slick interface appealing to the rest of BE-users. I don't believe it makes sense to fit the current backend to the lower end users." --Kasper 16:11, 20 June 2006 (CEST)

Sorry, does this not make most of BE user management obsolete? What do I need to configure BE users for if I can just give them access to the "light version"? And what if that user becomes more confident and wants more features? Should he be "promoted" to be allowed to use the full version? Or could I (as admin) customize both light and full version? Would these two versions not at some point become intermingled? Not sure about this ... might be worth a try but I have doubts. (-marion)

Typo3abc is not done, and I understand the confusion. Marion, I think you would be absolutely right if there was only one level in Typo3abc. And there is only one in the present "public beta", so you are in fact right :). But to a complete "slick editor´s interface would of course be levels and things to be configured. Let me put it this way, I will try to make a parelel; We all know MS Word. That would be equal to "the slick Editors Backend" I am talking about. Then there is "Visual Basic" that can be used to completely re-configure MS Word. That would be equal to "the competent programmers Backend" I am talking about; Both flexible and in variations. But all together very different - one is for editing and publicating, one is for programming and configuration. Typo3abc is merely a humble start of a project that aims to give a shot at "MS Word / Editors frontend". And just as you can change which toolboxes you have in word as an ordinary user, there will be ways of / levels of diferentiation in Typo3abc. It is just not there in Typo3abc ...yet, hence the confusion. (-Frits Lyneborg)

I love this conceptually, but I think the ideal will sit seemlessly between the simplicity of your functions and the full BE. I would expect to see 'admin' controlled interface elements to allow all users to share the same BE elements at an evolutionary level rather than light or full. This probably means micro wizards/modules and the easier ability to show/hide BE functions and modules. Your light idea could be integrated through light modules allowing different levels of users to show hide the easy/advanced function as they feel comfortable. (matthew)

1-2-3 with self explanatory site

Maybe we should provide a fourth step in the 1-2-3- instal where at the end we create/import a site helping newcomers? A better replacement for dummy...?


TOP TASKS?

Usability involves identifying WHAT is usable and considering if there are problems to be fixed. This page seems to miss out the valuable research stage. Ideas: 1) Identify through a logging extension? top paths through TYPO3 BE of the installations already out in the wild. This is likely to highlight unused areas of TYPO3 BE and overused areas of TYPO3 BE. 2) Critically follow paths and consider if they make sense. 3) Add a feedback extension to TYPO3 BE allowing people to contexturally submit 'in the wild' reports back to TYPO3 for logging and analysis. Anyone already have this experience with corporate software etc? (matthew)

My understand is that the task of converting (because truly it would be a conversion) to a more usable version of Typo3 would require very little real research. The quantity of outstanding usability issues is overwhelming - it will not require tests or statistics as much as a change in development attitude. Though fixing 100 small issues in 4.x will help, and talking to users is useful, what is truly needed is someone to oversee all areas of development and certify that the feature set is tight and well documented, the behavior is expectable, the UI is clear and uncluttered, the text copy is immediately understandable, the API consistent, and so on. In short, a shift in concept from "developers have free reign to do as they like" to forcing a fair amount of best practices and including the additional developer requirement "...and it must make clear sense to the end user" to every feature built.

I'll put it simply - If there was a "help this does not make sense" button in the BE, a new Typo3 developer would spend 50% of his/her time pushing it. (sudara 04-07)