Relay Alerts to the top of the view page

Proposal summary

I don't find the fading technique the most important aspect. But I do see the added value of a dynamic page top that notifies the user of changes or messages.

What I would like to keep: a block at the top of the topic that is visible when we want to show the user a notification or error message. The message that is normally shown in a separate (oops) page would now be prepended to the topic text. Of course skin authors would be free in the design of that info block. Personally I would be reluctant to fancyfy this.

Motivation

Sometimes you get an alert page, like this one:

1. This is a long text with details
2. This breaks the flow
3. I need to make the decision to continue
4. I need to find the link to continue

Ruby on Rails has solved this differently. Any note can be put as a temporary notice at the top of the page - this is called a Flash. A Flash is commonly a yellow block that fades to transparency in a few seconds, giving attention to this item.

The fading technique is called the Yellow Fade Technique.

For:

• Info by the 'inventors' - The YFT makes it super easy to spot edits/changes yet its unobtrusive nature lets people quickly get back to work once a modification is confirmed.

Against:

• Yellow Fade Technique Is Often Ignored - In other cases, the user was looking at the page when a big yellow fade fired off. He didn?t notice it at all. Why? Because it was ad-like.

Update: in TaDa list the fading technique works extremely well: video

Examples

LinkedIn:

Also copy is affected

Just a different display won't do it. The message needs to be short and to the point. For example:

With no renaming (all links are dummy):

With renaming:

Resources

• YourTotalSite.com / Yellow-fade technique for dummies shows how it works: onload example, clickable example, code in a zip - (I haven't looked at the code yet)
• Fade Anything Technique

What needs to be done

In all skins a container needs to be created to hold an action message (different from a more permanent system message like BROADCASTMESSAGE)

In PatternSkin the template directive flashnote looks like:

%TMPL:DEF{"flashnote"}%%IF{"defined FLASHNOTE and $FLASHNOTE != ''" then="$percntTMPL:P{$quotflashnote:contents$quot}$percnt"}%%TMPL:END%
%TMPL:DEF{"flashnote:contents"}%<div class="twikiNotification"> %FLASHNOTE% </div>%TMPL:END%

That is: if variable FLASHNOTE is set, its contents is displayed inside a html div with class twikiNotification (if empty, no div is created). The directive should be rendered just above the topic text.

Open questions

• How permanent is the message? Should a common closing button be used? Not that common, but iGoogle has it.
• What happens if you reload the page? Should the message still be visible?
• What happens if multiple notes are set, for instance by core and by a plugin? Should this result in a list of notifications?
  • TWiki does not have a way to deal with lists in templates.
• Should we strive for a generic visual style of the box, regardless of the skin?
• What notifications can we implemented using this mechanism?
  • Create a list of messages, for instance from messages.tmpl

-- Contributors: ArthurClemens

Discussion

Summary of previous discussion:

• This may be feature creap
• We need to do our best to remove irritating factors, by hiding complexity for users
• We must be careful to let these messages no look like error messages or dialog windows: these are friendly notifications of a change.
• This should not be a javascript popup. People don't read such a popup, and just close it, thinking it is an advertising.
• But.. users don't seem to read the non-closeable broadcast message either - there are at leasr 4-5 users that register on develop daily. People just do not pay attention if the're not looking for it.
• Plugins will also benefit from this mechanism. For instance SubscribePlugin can improve user feedback.

---

PatternSkin has implemented FLASHNOTE. This can be activated by setting:

• Set FLASHNOTE = This is a notification at the top of the page

Next steps:

1. Add this to default templates
2. Provide a core mechanism for code and plugins to set the variable

-- ArthurClemens - 07 Jan 2009

Here are some related jquery plugins:

1. http://sandbox.timbenniks.com/projects/jquery-notice/
2. http://kitchen.net-perspective.com/open-source/purr/
3. http://www.fragmentedcode.com/jquery-growl/
4. http://stanlemon.net/projects/jgrowl.html

I guess they can easily be enhanced to change style on notification type (notice, error, warning, ...) like these:

Note that this approach won't need a skin change. They do have the advantage that multiple async events may produce a flashnote without kicking out the previous one.

-- MichaelDaum - 16 Jun 2009

Here's an interesting demo of unobstructive user feedback using transparent messages:

And here's the jquery.message plugin to make it happen. Released just today.

-- MichaelDaum - 19 Jun 2009

I would love to have this. But it raises a number of questions:

• what would be shown if jquery is not used?
• what would be shown is javascript is disabled?
• would an unobtrusive message have different text?

-- ArthurClemens - 19 Jun 2009

Well my stance is:

• I am committed to jquery ... the project as a whole should do that step as well ... see MoveToJQuery
• the only situation where javascript is not available is during printing, e.g. generating pdf. that does not play a role here. wanting do deal with browsers that have no javascript enabled is not realistic anymore today ...

Let's move on.

-- MichaelDaum - 20 Jun 2009

If we choose a jquery solution, FW core and plugins must rely on its existence. So that needs an API.

-- ArthurClemens - 05 Jan 2010

jquery is now part of the package.

-- ArthurClemens - 24 Feb 2012