Not only looks -- directory search missing :-(
on
Google Updates Its Face
·
· Score: 3, Interesting
This is not just a change in look and feel. Google has also removed functionality. Previously, web searches was matched against Google Directory (dmoz). The result was presented in two ways:
If your search matched a category, it was displayed at the top.
If a particular hit matched a site in the directory, the category for this site was shown above the "URL - cached" line of the hit.
I think this is a sad loss of functionality. The link to directory categories served two purposes for me: First, it was some kind of extra "quality" check -- if a web site was listed in the directory, it was more likely to be the site I was looking for. Second, it informed me in a non-intrusive way that a directory category existed that'd probably help me in my search.
And to add insult to injury, Google has removed the simple link to Directory from the "tabs", so you have to first click "More>>" to find the Directory search, making it even hard to use it. I wonder if this is the first step in stopping to support the dmoz directory?
Fact: i-Mode has been a huge success. WAP has (not yet) been any successful.
Reason: i-Mode is based on packet switching. In the GSM network, there is currently no way to do packet switching. So, WAP of today must use circuit switching, which is slow to connect, and expensive.
This is what matters between i-Mode and WAP of today, not the difference between HTML-c and WML.
Fact: NTTDoCoMo can't implement packet switched i-Mode without a packet switching protocol. So, bringing i-Mode outside Japan will make i-Mode exactly as bad as WAP.
But WAP is built to be forward-compatible with the coming packet switching standards. GPRS is soon here, and will allow packet switched data. When that time comes, the difference between WAP and i-Mode will be of no interest.
So the whole article seems quite uninformed to me. Just because i-Mode was a success in Japan doesn't mean you can take that protocol to another network.
As a Swedish citizen, most of the time I prefer.se URLs to.com/.net/.org. An address ending in.se signals that this is a company/organisation based in Sweden, with a web site in Swedish, and with an understanding of local issues, etc. Even if I understand English (and have been forced to understand more of American culture and attitude than I'd really want to), I certainly prefer a Swedish company to an American.
The web *IS* about geography, only you Americans haven't realized yet! If you think that all.com's are American companies, then of course it seems hard to motivate the use of.us. But.com's are not all American anymore. There are lot of Swedish companies in the.com namespace, and from other non-US countries too, I assume.
When you start finding a lot of those sites, such as http://evreka.com, I think the need for a US specific name space dawns upon you.
That you have an archaic system for partitioning the.us is another matter. The discussion of bringing that system up to today's need has appearantly not really begun yet, but in other countries old and inappropriate rules of their respective ccTLD have been debated (and in most cases, fixed) since long time ago.
BTW, most library software is so atrocious, buggy, and difficult to use that it's writers would receive a failing grade if it had been turned in as a senior project at any half way reputable college.
You could say that again. Of all library cataloging software I've seen (as a patron, not as a librarian), they've all been about the worst examples of bad usability design I've ever come across!
If it wasn't so sad, it'd actually be amusing how you can fail so miserably at designing at least something with an acceptable level of usability for such a trivial task as searching for a book. And we are talking about systems that are to be used by the general public, people with sometimes little or no computer experience, and most of the time no experience of (or interest of learning) the current system. Sporadic, one-time users. Designing good interfaces in these circumstances is hard, but with the systems I've seen, no one has even tried to do something about it. It is really a shame.
This is a typical problem of closed-source software. Presumably, the libraries has chosen their current software for some properties such as compability with their older data and legacy systems, or speed of searching, or whatever, and never thought about (or prioritized) the user interface. And, since the software is closed-source, they are stuck with an interface that sucks. I really wish open source would be entering this area, since that is about the only hope of ever improving the situation as I see it.
Writing good user interfaces is hard. Most users don't realize what they want, they just perform well and are happy when they get to use good interfaces. User feedback as in "wish lists" or bug reports does help to improve usability, but not much. In modern usability designing, user studies where you observe the user when he/she uses a program, and notes where the user are having difficulties, is fundamental. How can user testing be adapted in the OSS world?
Making usable interfaces is about understanding the user's situation, his/her knowledge and goals. But it is also about innovation.
Take a popular UI for example: the shell. As most Linux users know, the shell is in many ways an excellent interface for performing certain tasks given certain knowledge. (This does not mean it's good for most users or most task, but that's another story.)
Imagine that your first contact with a shell ever was a shell without command line history or filename completion. (Which was probably the case for people who suffered with COMMAND.COM before starting to use Unix.) Now, how would you even come to THINK that you would like to have command line history and filename completion? Most users just DON'T, not until they try it out (and start loving it). If COMMAND.COM was an OSS project, how would the developers know that this kind of functionality was needed?
One way would be user studies: if you are studying someone using the shell, you'd see that he or she often are repeating an previously typed command line, suggesting the history as a way of speeding this up. Or that a common sequence of operation is listings files in a directory, and then trying to type the name of a file in that directory, with typos and slow operations as a result -- suggesting filename completion (of course, other solutions would be possible).
The interesting question imho is: can the OSS community incorporate user testing in the development process? If so, how should it be done?
And perhaps the most difficult problem of them all: how could one possibly convince the programmers to listen to and respect the outcome of a usability evaluation?:-)
Actually, the power switch sign (|)is an ISO standard. For switches with two different positions, they should be marked | and O for on and off, respectively. The (') is the standby switch sign, showing that the machine won't lose power completely.
Perhaps these symbols aren't the most intuitive in the world -- but then you tell me what a intuitive symbol for "power on" looks like! The ISO committee failed, and realized that the next best thing to intuitive symbols is standardization. Since the (|) and (') are fairly common, people learn their meaning anyway, even if it's not "intuitive" from the start, it'll soon become familiar -- and that's what intuitive UIs really are about.
The Internet Engineering Task Force (http://www.ietf.org) is working on an instant messaging standard, known as IMPP (Instant Messaging and Presence Protocol). The Working Group has a few Internet-Drafts available at http://www.ietf.org/html.charte rs/impp-charter.html, but no RFCs yet.
My impression is that the design of this protocol (in opposite to e.g. ICQ) is good, and I think this will be _the_ IM protocol to use, when IETF's work is finished. AFAIK, at least Microsoft is going to use IMPP (this is the "open standard" referred to during the IM war with AOL).
Slashdot Mirror
- If your search matched a category, it was displayed at the top.
- If a particular hit matched a site in the directory, the category for this site was shown above the "URL - cached" line of the hit.
The old behaviour can still be seen when using an odd language setting (like Swedish chef). See for instance this search for "java":http://www.google.com/search?hl=xx-bork&q=java and compare it with the new google interface:
http://www.google.com/search?hl=en&q=java
I think this is a sad loss of functionality. The link to directory categories served two purposes for me: First, it was some kind of extra "quality" check -- if a web site was listed in the directory, it was more likely to be the site I was looking for. Second, it informed me in a non-intrusive way that a directory category existed that'd probably help me in my search.
And to add insult to injury, Google has removed the simple link to Directory from the "tabs", so you have to first click "More>>" to find the Directory search, making it even hard to use it. I wonder if this is the first step in stopping to support the dmoz directory?
Fact: i-Mode has been a huge success. WAP has (not yet) been any successful.
Reason: i-Mode is based on packet switching. In the GSM network, there is currently no way to do packet switching. So, WAP of today must use circuit switching, which is slow to connect, and expensive.
This is what matters between i-Mode and WAP of today, not the difference between HTML-c and WML.
Fact: NTTDoCoMo can't implement packet switched i-Mode without a packet switching protocol. So, bringing i-Mode outside Japan will make i-Mode exactly as bad as WAP.
But WAP is built to be forward-compatible with the coming packet switching standards. GPRS is soon here, and will allow packet switched data. When that time comes, the difference between WAP and i-Mode will be of no interest.
So the whole article seems quite uninformed to me. Just because i-Mode was a success in Japan doesn't mean you can take that protocol to another network.
As a Swedish citizen, most of the time I prefer .se URLs to .com/.net/.org. An address ending in .se signals that this is a company/organisation based in Sweden, with a web site in Swedish, and with an understanding of local issues, etc. Even if I understand English (and have been forced to understand more of American culture and attitude than I'd really want to), I certainly prefer a Swedish company to an American.
.com's are American companies, then of course it seems hard to motivate the use of .us. But .com's are not all American anymore. There are lot of Swedish companies in the .com namespace, and from other non-US countries too, I assume.
.us is another matter. The discussion of bringing that system up to today's need has appearantly not really begun yet, but in other countries old and inappropriate rules of their respective ccTLD have been debated (and in most cases, fixed) since long time ago.
The web *IS* about geography, only you Americans haven't realized yet! If you think that all
When you start finding a lot of those sites, such as http://evreka.com, I think the need for a US specific name space dawns upon you.
That you have an archaic system for partitioning the
BTW, most library software is so atrocious, buggy, and difficult to use that it's writers would receive a failing grade if it had been turned in as a senior project at any half way reputable college.
You could say that again. Of all library cataloging software I've seen (as a patron, not as a librarian), they've all been about the worst examples of bad usability design I've ever come across!
If it wasn't so sad, it'd actually be amusing how you can fail so miserably at designing at least something with an acceptable level of usability for such a trivial task as searching for a book. And we are talking about systems that are to be used by the general public, people with sometimes little or no computer experience, and most of the time no experience of (or interest of learning) the current system. Sporadic, one-time users. Designing good interfaces in these circumstances is hard, but with the systems I've seen, no one has even tried to do something about it. It is really a shame.
This is a typical problem of closed-source software. Presumably, the libraries has chosen their current software for some properties such as compability with their older data and legacy systems, or speed of searching, or whatever, and never thought about (or prioritized) the user interface. And, since the software is closed-source, they are stuck with an interface that sucks. I really wish open source would be entering this area, since that is about the only hope of ever improving the situation as I see it.
Writing good user interfaces is hard. Most users don't realize what they want, they just perform well and are happy when they get to use good interfaces. User feedback as in "wish lists" or bug reports does help to improve usability, but not much. In modern usability designing, user studies where you observe the user when he/she uses a program, and notes where the user are having difficulties, is fundamental. How can user testing be adapted in the OSS world?
:-)
Making usable interfaces is about understanding the user's situation, his/her knowledge and goals. But it is also about innovation.
Take a popular UI for example: the shell. As most Linux users know, the shell is in many ways an excellent interface for performing certain tasks given certain knowledge. (This does not mean it's good for most users or most task, but that's another story.)
Imagine that your first contact with a shell ever was a shell without command line history or filename completion. (Which was probably the case for people who suffered with COMMAND.COM before starting to use Unix.) Now, how would you even come to THINK that you would like to have command line history and filename completion? Most users just DON'T, not until they try it out (and start loving it). If COMMAND.COM was an OSS project, how would the developers know that this kind of functionality was needed?
One way would be user studies: if you are studying someone using the shell, you'd see that he or she often are repeating an previously typed command line, suggesting the history as a way of speeding this up. Or that a common sequence of operation is listings files in a directory, and then trying to type the name of a file in that directory, with typos and slow operations as a result -- suggesting filename completion (of course, other solutions would be possible).
The interesting question imho is: can the OSS community incorporate user testing in the development process? If so, how should it be done?
And perhaps the most difficult problem of them all: how could one possibly convince the programmers to listen to and respect the outcome of a usability evaluation?
Actually, the power switch sign (|)is an ISO standard. For switches with two different positions, they should be marked | and O for on and off, respectively. The (') is the standby switch sign, showing that the machine won't lose power completely.
Perhaps these symbols aren't the most intuitive in the world -- but then you tell me what a intuitive symbol for "power on" looks like! The ISO committee failed, and realized that the next best thing to intuitive symbols is standardization. Since the (|) and (') are fairly common, people learn their meaning anyway, even if it's not "intuitive" from the start, it'll soon become familiar -- and that's what intuitive UIs really are about.
The Internet Engineering Task Force (http://www.ietf.org) is working on an instant messaging standard, known as IMPP (Instant Messaging and Presence Protocol). The Working Group has a few Internet-Drafts available at http://www.ietf.org/html.charte rs/impp-charter.html, but no RFCs yet.
My impression is that the design of this protocol (in opposite to e.g. ICQ) is good, and I think this will be _the_ IM protocol to use, when IETF's work is finished. AFAIK, at least Microsoft is going to use IMPP (this is the "open standard" referred to during the IM war with AOL).