Monolog Boxes and Transparent Messages
We’ve all seen dialog boxes that look like the picture on the right.
Dialog boxes are bad enough: they pop-up at inconvenient times, they derail our train of thought, and normally we don’t even read them. But this type of dialog box is worse. It’s not even a dialog box. It’s monolog box. There’s nothing one can do with this messages but click “OK”. Or wait and click “OK”. They have, as I’ve explained before, 0% efficiency. Beyond that, monolog boxes can have frightening consequences: because I often use two monitors, I’ve spent panicked seconds thinking I’d lost my work due to a crash… only to discover later that a monolog box had appeared on the other screen and stopped Word from operating normally. Even with a single monitor, you can miss the dialog box, and you’ll have a similar scare.
In the article The Spelling Check is Complete by Jensen Harris (of the Microsoft Office User Experience team) defends the “Word has finished spell check” monolog box shown above, along with the “Word has finished searching your document” box. The Office team had tried removing those documents but discovered that “people who were spell checking their document manually had no idea when the process was complete.” Thus, the monolog boxes were reinstated.
This is classic inside-the-box thinking. The problem is valid: people have trouble knowing the process is complete. But the solution isn’t to use monolog boxes. I can think of two different—and better—solutions. You can probably think of more.
Solution 1: Bypass the problem
Implied in the justification for reinstating the monolog boxes is the false idea that spell check is a fundamentally modal operation. In Jensen’s words:
“Spell check is one of those great features that have a beginning, a middle, and an end. The beginning is you clicking the spell check button. The middle is the computer conversing with you about potential misspelled words and giving you an opportunity to fix them. And the end is the computer telling you that the process is complete.”
But Spell check isn’t necessarily a modal interaction at all. Word’s own spell-check-as-you-type feature is a great example of a non-modal spell check. The text is underlined with a red squiggle: you only need to “converse” with the computer if you decide to fix it. The Gmail spell check, although ever-so-slightly modal, is another example of a spell check that does not require a “conversation”: spell check is done when you are done. Besides obviating monolog boxes, non-modal spell check has another benefit: it isn’t mutually exclusive with writing. If you are correcting a misspelling and you see something else you’d like to change, you can do it without exiting spell check. Your train of thought is never endangered—let’s see the standard Word spell checker and it’s monolog box do that!
Solution 2: Think outside the (dialog) box
If you keep Word’s somewhat antiquated spell check mechanism, then it’s true that the user needs to be informed when Word has finished spell checking. As I’ve explained, a modal monolog boxes are dangerous and inhumane. Luckily, there are many other methods of presenting information that are not modal. In particular there is one we are using in Enso, our upcoming product: transparent messages.
Transparent messages are the brainchild of Jef Raskin. It’s simply a large and translucent message that’s displayed over the contents of your screen. They fade away when the user takes any action (like typing or moving the mouse). In practice, the message is both noticeable yet unobtrusive. And because the message is transparent, you can see what’s beneath it. It’s just humane. Take a look:
Message Log
Transparent messages, however, introduce a problem: messages disappear easily. What happens if the user wants to see what it said? The solution is message log—simply a list of past messages. This way if the user doesn’t have time to read a message, they can go to the message log to view it only if they think it is important enough. And think about it: a message log would be a great thing to have anyway. How many times have you wanted to reference the contents of a dialog box and couldn’t because you had already dismissed it? And how many times have you had to transcribe the contents of a dialog box because the text wasn’t selectable? The lives of users and the lives of tech support staff would be greatly simplified by the addition of a system-wide message log.
On the web
The transparent message also has a place on the web. Web designers have a constant struggle to come up with non-obtrusive means of conveying fleeting feedback to users. For example, validating user input and checking login credentials. It is in instances like this that the transparent message really shines. Give it a try below.
The correct email is trans@parent.com and the correct password is pass. Make sure to play with incorrect login information.
Feel free to nab the source code.
Conclusion
Transparent messages are a simple and elegant solution to a problem that is normally either over-looked or over-engineered. They’re not right for everything, but for messages that need no user interaction, transparent messages are hard to beat: they have an efficiency of 100%.
Plus, they look pretty.
RT @azaaza Monolog Boxes and Transparent Messages | Follow @azaaza on Twitter | All blog posts
[ICR]
I very much like your demonstration, but I would say you need a certain tollerence on the mousemove, so it doesn’t fade until a significant move. This would decrease the percentage of times the user accidently dismisses it because they accidently jogged the mouse.
I agree with this post alot, toasts are a very good was of conveying information to the user in a non-workflow destructive manner.
cold wolf
ICR: Thanks to the fade effect, large text, and short messages, the user would have to be near-blind to miss them, even if they moved their mouse immediately after clicking Login (which is actually rare as I have observed, because the user waits for something to happen, then moves the mouse).
And if you just use the keyboard like I do, it won’t go away until you correct the text or move the mouse to browse after you hit Enter.
Needless to say, I dig the post. Well done, Aza.
Chris C.
Very nice. I’m wondering if an application like Growl had any influence?
Sushu
Whoa… That is … disconcerting. I’m like a little hamster trained to click “ok”. When the message popped up, I didn’t know what to do. I couldn’t deal with the message itself by clicking the “okay I see you please go away now.” If I hit “enter” in the sense of “okay, I got it”, the same message pops up, since Enter essentially resubmits the form. Instead, I had to *keep going*, move something else completely unrelated to the message box.
My little hamster brain has developed a way of dealing with pop-up messages that is inhumane, so now humane-ness is scary. But then again, habitualization is one of those human things, right?
Aza Raskin
Chris: Our transparent messages were conceived and developed independently of Growl. That said, Growl is a wonderful idea and looks great.
Sushu: You make a good point. I am reminded of when I started using Windows and kept right clicking to make the context-menu go away, thereby making it reappear over and over again. The problem was that the dismissal gesture had been overloaded with the do-it gesture. The same problem applies here. It can be solved by making sure a fading transparent message cannot be replaced with the same transparent message. I’ve implemented that, so give it a try.
User testing, as always, rules the day. Thanks for pointing out the problem!
Gary
On the subject of the evils of dialog boxes, I’d recommend Alan Cooper’s About Face for those who haven’t read it.
I really like the HTML-enabled Live comment preview. Thanks very much!
I’m not sure if it’s appropriate to comment here on the design of the blog design itself, but the font used in the body of the post could be a little bit darker (for my taste). The lower contrast is especially noticeable on my screen when text is italicized. The palette of grays and colors has a pleasant Tufte-ness about it, though.
Ross Hill
You speak of usability yet how do I get to your homepage from here? I think I will have to go to the location bar and do it manually?
Gotcha ;)
Sandy
Even a little research data rather than opinion would make this a stronger article.
Pinaki "Pakman050"
This is a great idea for a design pattern… very useful for exit disclaimers and other forms of disclaimer’ish messaging + loads of other uses.
Jeff Raskin does it again!
Jens-Petr
cold wolf: actually, i have to agree with [ICR] on this and i would encourage you to observe the mouse move threshold for message dismissal, when a tablet is the user’s input device. i find that even with a reasonably steady hand, the message is dismissed as the stylus rebounds from the tablet surface – the sub-pixel accuracy at play no doubt…
Ashley Gadd
ICR predicted exactly what I did.
I clicked the button and immediately moved the mouse. I was still focussed on the login box closer to the bottom of the screen when a flash of green appeared in my peripheral vision. By the time I glanced at it it had already disappeared.
People move the mouse for lots of reasons. Often when I initiate a process like logging in I immediately swap to another application while I wait for the process to complete. In this case I was just twitchy: I moved over the button, clicked, and moved away without thinking. Some people have palsies.
This is a cool idea but it does need to be tuned carefully. Aza, take a look at Office 2007’s Floatie/MiniBar concept, which starts very transparent and becomes more solid the more you move towards it. The Office team reportedly spent a lot of time tuning the “shyness” of it.
Usability testing will also tell you a lot about how people react to this.
Also, it’s important to connect the transparent message to the message log, otherwise people won’t know where to look when the message goes away. Having the message “genie” into the taskbar icon for the message log would be one way to do this.
Interesting ideas that, I think, will come to fruition before long.
Vitorio Miliano
Did no-one watch the movie? The narrator ends it with, “…our upcoming product, Enzo…”. Enzo? Andso? As in, the dialog is no longer modal, “andso” you can keep working?
Something with system hooks that replaces all modal and global modal dialogs with only one button with transparent overlays?
neha modgil
I am a very fidgety person and the mouse moves a bit too often. I clicked Log in and the message came up. It was in a font that noone could miss but I immediately moved the mouse and lost it :(
Also, I was thinking, if there are more than one error messages on the form, how will this work.
I would prefer a message that would go after a certain period of time (which can be determined by the reading speed of users)
Janine
I like this idea and will consider transparent messages in future. In cases where you still want something a bit more affirmative, like a proper confirmation I would want these to be presented in a way that blends with the transparent messages though. Of course these are two different things, and on screen they should look different, but they are related in someway and shouldn’t look completely alien to each other. Could be tricky. But great post! Thanks.
Oh and sorry for being slow, but how do I get to your blog homepage without the back button or editing my address bar?(!!!) The logo at the top isn’t clickable… I feel confused and second-class now.
Richard Karpinski
I got confused about what to do with
trans@parent.com
so I clicked on it and sent mail off.
I suggest that the example not have an email address which becomes executable in some browsers. Just use a “login name” perhaps.
None of the messages seemed transparent.
dreamchimney
does this require MochiKit 1.4 or should 1.3 work with this too ?
Peter
So when did Jef write about this?
It has been implemented in Mac OS for some time. It’s great to know that it was the brainchild of Raskin.
Image is from Mac OS X 10.1 and show a transparent overlay that pops up when you change the volume, eject a cd et cetera. I don’t thnk it was available before that. Circa 2001
peter
Ooops. Sorry.
Hm. Image worked fine in the preview.
Heres a link instead:
http://arstechnica.com/reviews/01q4/macosx-10.1/images/volume-overlay.gif
Blake Scarbrough
I like this solution for status and messaging that a task is complete, but I don’t think it is the right solution for indicating error messaging like in the example above. The messaging goes away when the user goes to correct it, and possibly wouldn’t know what to correct.
Joe
Where is this _live_ comment preview? How about this? This is really cool. Indead.
Anonymous
Hmm, says email address is requied, yet you can post without.
Anonymous
I found 2 bugs.
1. Message is displayed underneath YouTube flash plugin box so you cannot read it.
2. In IE6 if the User/Pass text boxes are near the bottom of the browser window, then for some reason the message is displayed and immediately disappears. If the user/pass texrt boxes are in the center of the browser window, the message stays around until you move the mouse.
niyue
Is there live demo available?
Paul Watson
Adobe’s Lightroom does a good job of this alerting you to undos with big, transparent text that fades away. You always know that the undo function happened and exactly what was undone while not interfering with what you are trying to click on screen.
Andrea
- Flash is a bad beast about overlapping with divs… This will be fixed in IE7 and is fixed in FF
- The demo is in the middle of this page, the small form. Try it.
- Great work, Aza :-)
Anonymous
Message pops up underneath the flash plugin in FireFox.
Stephen
I have to say, I agree with those few who miss the messages. This technique is brilliant for short little happy messages like “You are now logged in” but for messages that tell the user something is wrong or tell the user they have something they need to do, it can be a pain.
I wonder if a good compromise would be to all the user to click on any part of the dialog box instead of having to aim at an “OK” button?
Kendall
My concern with the example is “is it accessible?” Could a blind person using a screen reader recieve those messages? I don’t have a screen reader to try it out, but is definitely a concern of mine. I like the idea of the article though. We need to move beyond the old limitations of the user interface and take advantage of new techniques that can provide a better user experience.
spacey
Hi,
i tried the javascript file and found its not working . first bug was , its says , addLoadEvent is not defined, i found following trick on some site :
function addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != ‘function’) {
window.onload = func;
} else {
window.onload = function() {
if (oldonload) {
oldonload();
}
func();
}
}
}
, but then it says, function DIV is not defined .
Can you guys please put a valid js file so that ppl can use it without problems…
thanks.
Mats
I really like the idea, and see many uasges for this. But I can’t get it to work on my own…
Do I need another library besides mochikit?
Mats
Okey, got it to work, it seems that FF and ie (not Opera) doesn’t like addLoadEvent() if you have a .
To get it to work properly call both functions from addLoadEvent().
Nigel
Just tested the sample log in and it does not work at all with my screen reader i get no announcement at all.
JPhantom
Hi, I am very interested in this concept. However, I noticed that you do not take into account people using the scroll wheel perhaps you could use an implementation of the following code in the initilization function?
if ( window.addEventListener )
{
window.addEventListener(‘DOMMouseScroll’, hideMessage, false);
}
window.onmousewheel = document.onmousewheel = hideMessage;
spacey
Dear Mats ,
can u please elaborate on ur comment abt adding both functions to addLoadEvent ?
thanks
Rhon
If you are having problems with the addLoadEvent, download version 1.4 of MochiKit. This fixed all of the problems that I was having.
Bryan Buchs
I hacked together a jQuery implementation of this, using the excellent Thickbox as a base. I’ve added a few things to it, including “Delay” and “Tolerance” settings.
“Tolerance” – won’t trigger dismissal of the Monolog unless the mouse is moved XX pixels (5 is my default). “Delay” does what it sounds like – there’s a slight delay after mouse move before starting the fade-out. I’ve also made the “Escape” key trigger an immediate dismissal.
http://bryanbuchs.com/tb_dialog/
Sander Voerman
The principle is nice and useful in certain circumstances, but the example is really flawed!
I think you need to make a distinction between location based user input (the form visible on the screen) and abstract user input (a menu command executed by a short-cut).
Whenever the user needs to get feedback on the login-form, the preferable place is around the form itself. In this case, using over-the-top feedback, the background of the login form should turn red and a big text message should be placed above or under the form itself, becoming a permanent part of the page until the user hits ‘Submit’ again. The message can be used as a reference of what was wrong (the username or the password).
In case of the spelling check, accessed by a keyboard shortcut instead of the check spelling subwindow, it might make sense to place the message on a ‘random’ location.
On the other hand, a much more logical approach would be to visualize the process. Which means that at the start of the spelling check something would be shown over the document itself displaying the progress, that turns into a dialogue in case an error is found. If no errors are found at all it might behave like the transparent message. In either way, the user knows the spelling check is finished because the ‘progress’ lay-over is gone.
Dieter
Hello!
I’ve taken a bit of a different approach to the JavaScript implementation of this and developed my own replacement for the standard JS Confirm and Alert functions. You’re more than welcome to take a look over at my site and let me know what you think.
Thanks,
Dieter
Paul Jenkins
I think the status bar approch to information is much more productive.
Braydon Fuller
Neither monolog boxes, or transparent messages are better. One requires more actions to dismiss the other requires less. One is easy to easy to not pay attention to, and the other is really easy to not pay attention to, depending on the situation.
Monolog boxes require more actions, and are thus more demanding, but will still become a habit, as Susha has reminded us. The function of having an OK button is to make sure that the user has payed attention to it, but this actually isn’t true because we could “OK” the message without understanding it. The solution would be to provide two ‘actions’ for habit formation: One action would mean “I understand it, now get rid of it”, and the other action being, “I don’t care about this right now, save it for later”.
Monolog boxes that appear after finishing a document, are a friendly reassurance that the entire document has been spell checked, thus to avoid the user checking the document multiple times, like someone with OCD…. I will gladly click on OK, like I gladly cross off a to do item on my to do list. Although… I should be able to tell I have reached the end of the spell check because I have reached the end of the document or selection, and I’d rather have the CHOICE to cross it off my todo list item.
The most dramatic example of a monolog box with a bully-attitude, is in Photoshop (i’m using CS1) where upon attempting to make a selection, and no selection is possible, a monolog box appears requiring you to say “ok”, where it is fairly implicit that no selection is made. This can happen repeatedly several times a minute. A transparent message that disappears on mouse movement would be better, in this context, but no message at all would be best, we can tell without a system message. :)
Going back to the monolog box that appears after finishing a spell check… It is a reassurance that the entire document has been spell checked… which could give a false confidence in that the document is without spelling flaws. While this is false. The message should say, “While the spell check is complete, it is recommend that you check to make sure that he computer did not make errors.” Thus the message is honest about the it’s own limited intelligence. It’s harder to get mad at something that admits it own shortcomings.
Braydon Fuller
I am willing to ok, ok, ok, ok, ok, ok, and ok again a monolog box, as long as my computer is doing something really exciting.
I would be will to ok, ok, and ok again, an interface that simplifies creating dynamic websites, and simplifies all the different profiles I have to fill out on all the social community websites. And simplifies all the of the various email accounts I have created.
Seeing the larger picture is the most pressing matter. It is what everyone is drawn to about the internet. It’s the same thing that draws people to religion.
What is also interesting is looking at how many people are playing massive online role playing games, why are they “wasting” all that time, what are they gaining? Respect, a community, love, and self-actualization? Some people have focused so intensely on playing WoW they have forgotten about their physiological needs, and died. Imagine if politicians exhibited this level of focus!
You know what is also frustrating is that your comment system is not as good as the system that is used on http://digg.com.
John
Honestly: Microsoft is correct — people want feedback. You have taken a small problem (or a non-problem) and designed a complicated solution to fix it. This is linked off the Yahoo UI page — otherwise, no point.
Cliff
I have to agree with John: this is a non-problem. As a matter of fact, the ’spell-checker-misses-misspelled-words-that-are -actually-words’ syndrome makes a wonderful point: When you’re spell-checking, you *should* be paying attention.
You say that the ‘monolog’ box breaks your train of thought, but the only situation I can imagine where you’d:
would be if you manually started a spell-check knowing that everything was spelled right, and that would be little more than a pathetic plea for praise, wouldn’t it?
However, a deeper issue does still exist… those little red squiggly lines tell us that words are potentially misspelled, but scrolling completely through a 200 page document to check for red squiggles is hardly efficient. Clicking ’spellcheck’ every time you want to know how you’re doing is just a faster method of the same inappropriate method – iterating through every word in the document.
You say to think outside the box… how about getting rid of the box altogether? These boxes, whether modal or transparent, walk a fine line between distracting our attention and not getting our attention well enough.
My first thought is to have some sort of passive ’spelling error status indicator’ somewhere… perhaps a macro that uses the SpellingErrors property and the CommandBarControls collection to display an icon on the toolbar – red if there are errors, blue if there are none?
Rafael Madeira
Ok the article islong and I haven’t had the time to read all the previous comments (my lunch time will be over in 2 minutes), so forgive me if I’m preaching to the choir, but I just have two suggestions to make:
1. Give the warnings a delay before fading out (this one I know to have been mentioned before). My first reaction after typing something is always to go back to the mouse (perhaps to get rid of monolog boxes as quickly as possible), so the messages disappeared as soon as I touched the mouse, hardly giving me any time to read.
2. Give imediate focus back to the fields, with the previous input selected, so I can just type again, instead of having to select the text again so I can type one more time. If it’s possible to narrow down what the exact error was (email or password), then give me the specific message (“the password you provided is invalid”) and focus on the appropriate input.
I can’t stress how perfect this would be. If anyone’s made those points before, take this as a reinforcement.
Spencer
Hi,
When working with the HP3000 with a language called PROTOS, back in the 80’s it had a very nice command called: “message”.
As a programmer you just call a procedure for example like this: message(“Finished Spellcheck”), and it would display that message in a specially dedicated line, like a Status Bar at the bottom of the screen. The message would appear there, maybe with a beep and/or a background color change and just sit there. No fade away, no button to press to dismiss.
It was perfect! No need to log, even it is a good idea, no problems with accidental fade aways. The user knows that that line is for messages and knows where to look them.
It was unobtrusive, no need to do it transparent. Even a transparent message can be intrusive.
Thanks,
Sp
Matthias
Oh that’s a really great idead! I like it.
Is there live demo available?
Zilqjala
very interesting
alaska fishing+ salmon southeast sport alaska fishing+ salmon southeast sport
karuna
Brilliant idea :)
Few comments though:
1. the transparent message is too sensitive (mouse move and the message is gone).
Sol – turn down its sensitivity a bit; we make it fade slowly and also the fading starts after a certain time interval.
2. despite slow fading, users may miss the message. Message logging is a great idea! But how does the user access these logs?
Sol – usually the user is concerned about the last few messages given out by the computer. So, once the message fades away, we display a concise version of the message on the top-right corner of the screen. Only the recent 5 messages are displayed in the corner (thinking the user wouldn’t be interested in the long list of all the messages) So, if the user lost the message, then he could still view it from the concise display and could expand it by clicking – which would give him a transparent but modal message displayed (without a OK button) which is closed by just clicking anywhere on the expanded message.
3. the article describes transparent messages as replacements to monolog boxes (informational messages). So, these are not directly suited for error messages or interrogative messages.
Sol – probably we could tweak the transparent messages a bit. For error messages, the disappearing act (fading not required) would kick off only if the user clicks anywhere on the message. We could have the message displayed on the top-right corner for later access. For interrogative messages (yes and no types), we should have two button like regions in the message display area. This is back to the usual dialog boxes, but atleast this way we would be consistent with other messages types and more friendly, since it is transparent.
The above would work for web pages too. That is, for each web page we maintain the concise display. The concise display could be linked to the message log itself.
4. the sensitivity of the transparent message should be dynamic i.e. on a mouse move the message will display slowly, if the user clicks on the message then it disappears instantly. This is required to make it less intrusive.
5. like somebody mentioned screen readers should be taken care of here.
6. also, the implementation of this for websites would require javascript. What would happen if javascript was disabled on the browser?
Sol – once we detect that JS is disabled then we could fall back to the old standard way of doing it.
Matt Helm
This is awesome. I can’t wait to see how this will be used in the future! Great job guys!
Scott
Hey,
I’ve always considered alerts the domain of sounds. Auditory feedback is very underutilized in the domain of human-computer interface. The question of course, is how to implement such a response.
A full fledged reading of the alert seems a bit excessive for a variety of reasons. The most obvious being the more complex and bloated alerts that would be hard to follow or dificult to translate to speech (try reading: “The site http://www.thissite.has/anexcessivename/2007/~64/etc/etc/etc does not exist”)
Alternatively, a simple beep doesn’t convey enough information for the variety of alerts that are worth noticing.
An already suggested way to deal with this is would be a generic auditory alert with a surreptitious info box somewhere that informs the user of the details of the alert. The benefits of this are varied and depend on the implementation (your job, not mine :), but I believe that this problem is worth approaching with priority on auditory communication instead of visual.
One side benefit of this is that it automatically deals with the screen reader problem already raised by a variety of people.
Scott
Eric
It is well made but not entirely useful. When designing a large web form with many fields, the location of the missing data is just as important as knowing that it is data is missing. Telling a person that there email is missing means nothing if the screen has a numerous (10+ ?) form fields. Some would argue that splitting a large form into steps would be the way to remedy this but this is not always what is the easiest to use solution. That said. This is nice and clean.
Mees
Live comment preview rocks ass!
Asrail
I agreed with some of the early comments, telling that should there be a delay for mouse moves after submission.
I say that because the first time I’ve submit the dialog disappeared immediately, due to the mouse movement of while I was clicking on the button.
apolefra
So… I wonder…
How
ugly
CAN
i make this post
YES!
Xygeqggg
214
214
christopher
test test
mmjj jjjll
kk
pratiz
The login example doesn’t seem to work on IE7
wILL
Most good Java development environments (e.g. Eclipse and IntelliJ) have a 10px column on the right hand side of the editing pane to the right of the vertical scroll bar.
They use this to display little coloured rectangles for hints, warnings, and errors on each line of the file – the bar scales as the file grows longer, and the document is checked in realtime. They even include ‘TODO’s that you’ve typed into the document yourself.
The little rectangles have mouseover tips so you can 1) see how much has to be fixed 2) preview each problem without scrolling 3) jump straight to any line without scrolling 4) you can ignore the lot of them if you want to.
bob
wow..yet another “ajax”-esque javascript demo that errors out when the page loads.
riveting.
macbirdie
What happens when such transparent message appears while I’m in the middle of pressing down during typing? Will it disappear immediately without giving me a chance to read it?
Balloon messages in Windows XP worked in a similar way. If the user wouldn’t use the computer at the time, the message used to stay on forever. In case of active use of the computer, they’d stay only for a few seconds. In either case the user wouldn’t miss it. But people were annoyed with balloon messages, ’cause they were abused by software developers.
SAzyjggg
56tr
56tr
TJ
I whipped up my own version real quick for a project I am doing now.
Might have a few bugs but give it a look:
http://www.tjeastmond.com/Human_Error/
ESTAN
This example seems to work overhere, but not when you try to use it. I am sorry guys, but this look bad ;-)
The error i’ve got is here:
Object expected when @ the if function
function getMessageOpacity(){
/* Returns the current message opacity. */
if (computedStyle( MSG, “display” ) == ‘none’) return 0.0;
return computedStyle( MSG, “opacity” );
}
curious reader
What about blind readers? If you’re going to provide “humanized” feedback mechanisms, don’t you think it might be a good idea to consider users who are using Lynx, i.e. a non-graphical, Javascript-disabled interface.
Frank
Nice and useful change, but i would propose to automatically fade the message away.
I mean, this message is not that important. The user doesnt’t sit there waiting all night to get his search doen, rather performs a quick search in between two thoughts. So, i think it only has to “exist” for about a second. No useless clicking or mousemooving. The computer shouts at you, but doesn’t interupts you.
And i would also like the idea of a talking computer, besides from the cool science-fiction touch, it would really help disabled users.
Nico
very good idea, but there definitely needs to be a minimum time that the message shows….. good idea, but needs tweaking
Red84
Am too pleased that I actually got it right, and in about 5-10 seconds too. ,
Zayıflama Lida Fx15 Ve Biber Hapı Zlfvbh
ICR: Thanks to the fade effect, large text, and short messages, the user would have to be near-blind to miss them, even if they moved their mouse immediately after clicking Login (which is actually rare as I have observed, because the user waits for something to happen, then moves the mouse).