If you're writing to the API, how tied to it are you? With a rederkit, you can quickly make changes from a web-browser to a PDA, with the components taking care of the display issues. Is display migration an issue?
I would argue that that's a dangerous approach: If you have a single UI for two platforms with radically different display sizes, it's liable to be difficult to use on one or both. Not necessarily true for sites and very simple apps, but as you get into complex applications I think it would be a problem.
Still, way better than what I thought the parent most meant. If Mail.app, in trying to display attached images, executed such a script, then you'd be in a position where you couldn't even view a message without risk. That might have been enough to cause me to switch to Thunderbird.
As it is, we Mac users just find ourselves needing the same vigilance as Windows users (which many of us probably exercise already) in making sure attachments are legitimate before we open them.
I tried this in Mail.app...even modified the script to create a file on my Desktop to be sure...but nothing happened. The JPG script showed up as a file attachment but apparently Mail.app didn't try to display it.
Hoping that means Mail.app isn't vulnerable after all...
I think I speak for many Mac users in saying that our smugness (which is never really a good thing) is derived from how much easier it is to be a Mac user these days in the face of all the Windows security threats. It's reinforced, too, by a deeper confusion regarding why so many people feel like they *have* to use Windows. I'm secure in recommending Macs as a more secure alternative - not because I believe that Macs are inherently immune to attack, but because today's reality is that they're at much lower risk, and no matter how much I plead with my friends and relatives they're not diligent about security.
And that's the real problem. I take security measures with my Mac. But many people don't want to learn about or take the time to implement security measures. Windows security would be a whole lot better if every Windows user upgraded to XP SP2, turned on Automatic Updates, and installed a firewall. Add anti-spyware, anti-virus, and a non-admin account and things look even better. Mac and Linux users, at the very least, should have firewalls and should be careful about what they download and run. But by and large, people don't want to bother. And given that, a system that (a) gets fewer attacks and (b) comes configured without root privileges seems like a clear winner to me.
The longer-term challenge is how to manufacture computers that are secure enough out of the box to survive without user intervention...because most users won't take the time.
I definitely don't think desktop applications represent the epitome of usability. However, I think the average Web application is worse. A basic Web site may be better, in part because it's simpler - text, hyperlinks, and basic form controls. (Though a surprising number of sites manage to screw up the Web's basic usability with hard-to-read text and links that are indistinguishable.)
But once you get into real application functionality, I think the Web is a dangerous place. While desktop apps aren't perfect, the APIs and pre-built UI controls mean that a novice to interaction design can still put together an app whose components have been usability tested and behave in a consistent, expected way. Right now, any complex UI controls in HTML must be built from scratch, resulting in some combination of inconsistency, poor usability, and poor functionality. To do otherwise is difficult to impossible: Few people are experts in both Web development and usability, and even those who are have no official or ad hoc standards to build on. Does it act like a desktop app? Like a Web site? Like something else? There's neither a technical nor a conceptual framework in place.
I hope you're right that server-side toolkits will alleviate these problems. That would certainly close a major gap, though as I think we both agree there are still significant disadvantages (functionally) to any app that runs inside a browser vs. desktop applications. However, the task of creating good server-side support isn't trivial; requires good UI designers; and to be fully effective must be somewhat consistent across server-side frameworks. I fear it may be a while; meanwhile, Macromedia created a set of standard widgets that, regardless of what else one might think of them, allow for consistency and predictability and don't require developers to keep reinventing the wheel.
I also maintain that Flash is a better option architecturally. Even with server-side frameworks that take care of the details, the HTML, JavaScript, and CSS combo seems like a messy way to construct a complex UI.
In the end, I suspect we both agree that neither Flash nor DHTML/AJAX is an ideal platform for application development. We just disagree about which is the lesser of available evils.
Of course, it is: the secret behind the web's success is the developers and the fact that HTML and HTTP made it easy for them to deliver content and applications, while keeping them from doing the stupid things they used to do when programming applications for the desktop.
I both agree and disagree with most of your points. Yes, HTML and (to a lesser extent) HTTP made developing for the Web easy. No, it didn't keep developers from doing stupid things akin to the stupid things they do on the desktop. People will always make bad apps and publish bad content on any platform.
You're quite right that web technologies make it hard to layer application-like functionality on top of the web, and that's a good thing. It keeps people like you from treating the web as a desktop application delivery platform. You can either adapt to that, or you can get a different job.
It should be a good thing, but it's not because technical and usability considerations tak e a back seat to business ones. I don't like Web applications, but it's all I end up designing these days. I can argue until I'm blue in the face that the Web is the wrong platform for app development, but people choose Web over desktop applications because neither a download nor an install is required. It's hard to argue with that logic, when consumers and IT departments alike are reluctant to install things on desktops. So Web apps flourish, despite their limitations, and the best we can do until there's a viable alternative is make the best of it. DHTML and AJAX help; but again, I'd argue Flash is a better choice because it's better suited architecturally.
Yes, OpenLaszlo delivers typical Flash applications: applications that don't support cut-and-paste, ignore browser font sizes or preferences or screen resolution, don't provide accessibility, don't resize properly, and have numerous other usability problems.
Sorry...I didn't mean to hold up OpenLaszlo apps as a shining example of good Flash applications, so much as to provide an example. Of what I'm not actually sure now that I think of it. I think it's a neat idea but it could certainly use some improvement.
Flash is technically OK for little animations, which is what it was originally designed for. But Flash is a lousy web-based desktop application delivery platform; Java, RDP, VNC, and X11 would be far better for that and far easier to both develop for and use. But, in fact, it has turned out that the entire concept of a web-based desktop application delivery platform is flawed, which is why all those other platforms failed to catch on for mainstream web use as well.
Java: People got burned by Java early on; otherwise I'd agree. I haven't done much Java development recently, so the problem with Java may very well be one of perception at this point. That doesn't mean it's not a problem though. Java applets also tend to load slowly into browsers.
RDP: I like RDP. It seems snappier than some of the alternatives. If there were a cross-platform implementation at the app level (instead of the screen level) it might be a viable alternative to Flash and HTML.
VNC: VNC has always seemed slower than RDP to me, though it is cross-platform. Otherwise the same comments apply.
X11: X11 is exactly what the Web application platform should be. It is unfortunate that the X client/server model isn't built into either Windows or Aqua. With beefed-up security and some other improvements it could be the answer, and I think it's funny that 20 years later we're building apps in a poor imitation of it.
But again, the problem is not whether any of these technologies is better but whether it's viable. Delivering applications in HTML or Flash (which is installed on most desktops at this point) fits no-install, no-download requirement. None of the other options does.
And incidentally, as you move from traditional Web sites into Web applications with DHTML and/or AJAX functionality, the Back button becomes a problem even without Flash, as the browser's stored history doesn't necessarily correspond to the user's concept of browse history. In some cases a Back function may not even be appropriate.
Flash breaks just about everything about the web that made the web successful in the first place: open standards, text-based representations, user control over rendering, cut-and-paste, and screen scraping.
This is a list of useful attributes for developers and a very small number of power users, not a list of things that made the Web successful. Also, Flash supports cut and paste.
What made the Web successful was first, the ability to get information out to people easily; and later, the ability to get applications out to people easily (particularly e-commerce). In the first category Flash doesn't often come into play, though particularly with Flash 8's font smoothing it might make for more readable content. In the second category Flash is arguable better suited as a platform than HTML. Even with technologies like DHTML and AJAX you're still layering application-like functionality on a page-based platform and it's awkward. As an earlier poster pointed out, the fact that Flash is used for some bad sites and animations doesn't mean it's a bad platform. Take a look at OpenLaszlo (http://openlaszlo.org/) for one example of an interesting open source, Flash-based Web application tool.
Monopolies make me nervous too, but let's not confuse the existence of a monopoly with the quality of the technology in question.
AJAX apps will replace numerous desktop apps, but not because they're better. Vendors distribute products as Web apps because of a distaste for installing things by IT departments. Not requiring an install on every desktop can mean the difference between getting a sale and not. AJAX allows this to be less of a compromise in user experience, which in turn translates to competitive advantage.
Even in the Web space, AJAX isn't actually better than anything: Flash is arguably a more appropriate rich application platform and can do everything AJAX can. Java is an even better application platform. But I think people got burned by client-side Java when it first appeared and are wary of it now. In addition, turning your Web app into a Flash or Java app requires significant retraining and recoding, while adding some AJAX does not. Thus AJAX is an easier path to a better product in many cases.
AJAX is also not a silver bullet for application functionality on the Web. For example, an AJAX-based word processor can't directly open and close documents on the user's hard drive. While the solution doesn't have to be local file access, the current state of affairs isn't enough I don't think. Also, Web apps are stuck inside a Web browser, which means limited acces to OS-wide features and unfortunate ties to a UI designed for pages, not apps. These aren't limitations to AJAX only, but to anything confined to a browser window.
For the promise of AJAX to be realized on a large scale, some things need to happen. Web app frameworks need to incorporate it more. This has already started to happen with Rails, JPSpan, and others, but the integration needs to be tighter and the standard enterprise development environments need to incorporate it. In addition, AJAX permits much more application-like functionality but the Web only natively supports some very basic user interface elements. A standard set of elements, available to everyone with a consistent look and feel, will both make building AJAX apps easier and make for a more consistent, predictable user experience Web-wide.
Last, it's worth noting that you can do AJAX in earlier browsers than those that support XMLHTTPRequest. It used to be called Remote Scripting, and there's an excellent article on the Apple developer site describing the technique (http://developer.apple.com/internet/webcontent/if rame.html) as well as a library called JSRS that works in v4.0 browsers (http://www.ashleyit.com/rs/jsrs/test.htm).
Not sure I agree. I suspect that most home users user whatever software came with their computers. Despite the ease of doing so, few even update with any particular frequency. So they'll buy a new Mac in a few years, it'll run on Intel, it'll have new versions of AppleWorks and iLife and iWork, maybe they'll buy a MS Office upgrade with it, and the transition won't really affect them.
Then there are those of us who just bought 2.5GHz Power Mac G5's and expected them to last 4 years while working with the latest software...
Hmm...sounds doable. I would need to learn more about RoR to understand the details, but one would think that between the Web server config and the Ror config you'd be able to pipe the RoR output through the XSLT processor before sending it to the client.
I'm a user interface designer, and as such do a lot of HTML-based interactive prototypes or mockups for Web apps. I've been using XSLT combined with XML sample data files: The XSLT allows me to build up XML-based widgets for complex but common elements and then quickly create pages using them. For that it's great, but it can be a bit cumbersome in other respects. So I'm wondering: Is there any way to integrate RoR and XSLT? Use Ruby on Rails for some of the back-end stuff but keep my XSLT widgets for the front end? Or, alternatively, is there some equivalent platform for my XSLT widgets in RoR?
Actually, a UI should be judged on both. The balance varies depending on the intended user. A UI that sacrificies efficiency for intuitiveness is fine if it will mostly see infrequent, novice use. But a UI that will be used constantly for complex or repetitive tasks might justify a steeper learning curve in exchange for greater efficiency (for example, less extraneous mousing around). In the best case one doesn't have to sacrifice one for the other, of course, but sometimes it's necessary.
So what's a good alternative for SMB in terms of sharing files among a bunch of machines, potentially running multiple OSes? My understanding is that FTP isn't the most secure protocol either.
The "stop whining" approach is not going to help the GIMP supplant Photoshop.
Using a platform's window management to excuse any difficulties people are having with the product is not going to win over users. The platform is what the platform is, and for an app to be usable it must make the best of it. I hate MDI with a passion, but Windows has yet to produce a better answer to the Mac's global menu bar. If I were writing Photoshop for Windows I might use MDI too.
Responding to user complaints with things like "just set your windows up this way" or "just change these preferences" isn't a solution. I suspect the GIMP has lost and will continue to lose users who look at it, say "this doesn't measure up to Photoshop," and move on. The defaults cater to new users; advanced folks can customize.
I see several main UI advantages of Photoshop, comparing the Mac version (since that's what I use): - The global menu bar works well in a graphics app, because means functions aren't somehow tied to a single window. With an open document I suppose that's not such a big deal, but even so I think it's cleaner. - The palettes are smaller. The GIMP takes up a HUGE amount of space. I can't resize the toolbox down beyond 2 columns, and if I do that I lose most of the main app menus. The Small theme helps a little but doesn't really solve the problem. I don't think the GIMP is feasible to use at 1024x768. - Photoshop palettes are more clearly secondary windows. They disappear when the app is in the background; they can be docked; their positions can be saved. This makes for easy window management without much effort. This type of functionality would serve the GIMP well.
Obviously there's more to developing the GIMP than cloning Photoshop. But there are distinct advantages to cloning Photoshop: People like it; it makes transitioning to the GIMP easier; and Adobe has put a lot of thought into Photoshop, so presumably there are good reasons for many aspects of its interface and feature set.
My reaction to the book was simular to yours. The idea that captured my imagination the most was the concept of getting rid of applications all together and creating a system architecture based on documents and tools that operate on those documents. There are so many aspects of this idea that would cause it to be a very powerfull and flexible system.
It does seem like a good idea. And actually, Apple tried it with OpenDoc. OpenDoc's failure may not mean the idea is bad, though. But I do question it a little. Seems like we do work in the physical world based on concepts of documents and of tools, i.e. "that note I'm writing" and "the pencil I'm writing it with." Which is more important? What's an appropriate way of relating the two? I don't know. I'd like to see some good research on it.
One of his axioms was that you should never have to manually save a file, that it continuously trickles the changes you made to disk, as you make them.
I agree with his axiom, but I don't think it requires a different way of doing things. There are multiple ways it could be implemented without eliminating filenames (a rather simple one might be a "New Documents" folder on your desktop, but I'm sure one could do better). Not to say we shouldn't investigate, but without further evidence I don't think we should simply discard the possibility that names for things are useful.
I agree with your concerns about ZUIs. I've used and even designed for ZUIs and I think they can be very compelling, and are useful in a number of situations because of how well they represent a hierarchy and provide feedback for its relationships. However, the issues you cite seem reasonable and aren't something I recall Raskin addressing. I'd like to see this use of the ZUI addressed by thorough empirical testing.
It is interesting that so many UI experts are of the opinion that filenames and directories are a complete failure for the average user. All the people that I know organize their files just fine this way. I need to get around to reading the studies that cause them to feel this way.
I won't be so arrogant as to claim to be a UI expert, but I do do UI design for a living, and I'm not at all convinced that files and directories are a complete failure. I can think of some issues in their representation, but that doesn't mean we should toss them out. I, too, would like to see some research evaluating their effectiveness.
Interesting. Ultimately though, the question is not, "Do I use hierarchies?" or "Do you use search?" but: - Do people naturally use one or the other, a combination of both, or something else? - What combination of structures and information-finding mechanisms will best serve users? - What is the best balance between variety and simplicity?
I've also read his book, and found it alternately worthwhile and very frustrating. A lot of the basic principles he talks about -- such as the issues of modality mentioned by the previous poster -- are important, well-supported, and can in some cases be implemented within the current GUI framework.
However, he goes on to design what he calls the Humane Interface, and suddenly many of his arguments are based on sweeping statements that I have trouble taking at face value and that aren't well-supported. For example, he proposes doing away with folders, filenames, and indeed separate files altogether and allowing users to find whatever they need via an incremental search of their disks. Incremental search is useful, but I have trouble believing that most users would be able to remember the content, let alone the exact wording, of every document they wrote. I certainly find things myself according to where I put them (i.e. what folder, sub-folder, etc.).
For users who like hierarchies (who he feels are few), he proposes a system of pages, documents, and folders based on various numbers of page breaks. (Two for a document boundary, 3 for a folder boundary, etc.) To me this seems like shifting the burden of maintaining a filesystem onto the user to create the technical simplicity of a single document, and without empirical evidence I have trouble believing it's a good idea.
He goes on to add a zooming user interface to his system. I like ZUIs and think they're a neat way to browse hierarchies. But in the preceding chapters he has done away with hierarchical structure, and thus in adding a ZUI he is effectively adding a dual structure to his filesystem. Again, this seems to be increasing the burden on users' minds by asking them to track two parallel structures to their data.
As has already been pointed out by others, it also seems a bit odd that, in the end, so much of his book is devoted to scrapping the GUI in favor of something similar to the Canon Cat.
I agree with most of what Mr. Raskin has to say in this interview. Computers are inefficient and bloated. (I think the 1000-page manual example is a bad one, since the existence of numerous features is not in itself a problem for users uninterested in them.) User interfaces can be easier to learn and more efficient. Modern operating systems are converging on a GUI standard, which is great for cross-platform use but isn't pushing user interface innovation forward. In all these things he's dead on, and certainly not alone. But he seems to think he's found the answer, and I question whether he really has.
You are both right and wrong. "Ease of use" is a deceptively simple term that encompasses a number of important things including how easy a product is to learn; how efficiently an experienced user can use it; and how quickly an inexperienced user can become an experienced user. The new users who will have the hardest time are often those who are used to a similar product. Sometimes designers have to trade off these various factors against one another. But they're all worth considering and certainly a product can be better or worse in any category. You may get used to one OS or another over time, but that doesn't mean you'll be equally efficient using each, or that each will take the same amount of time to adapt to.
Actually, my impression is that Windows users aren't biased towards MS. They just have the impression that they have no choice. I think it sometimes makes them _harder_ to convince.
Overall, the multitude of distributions is a good thing. Every distro is designed with slightly different goals (and created with different skills), increasing the chances that a given person will find a distro that suits him. The fact that many distros are variants on a much smaller number of "base" distributions increases that, since it gives distro creators the chance to choose an already-stable OS and tweak and/or improve upon it.
However, there's one major drawback when it comes to adoption of Linux by new users. If I'm a Windows user looking to switch to Linux, I will quickly discover that "Linux" is in fact a large number of slightly different operating systems, and the task of switching to it may suddenly become extremely daunting. I hope that with time, this sorts itself out and the choice for novices becomes easier...I think it will.
BTW, I've installed Ubuntu on both a Powerbook and a Dell P4 without a hitch. Easy installation, easy to use. I like Fedora's customized Gnome layout and theme a bit better (and think it's a bit more usable), but good stuff nonetheless, and especially nice to have an easy-to-install, up-to-date distro for PPC.
It's a bad habit to get into, depending on a spell checker.
First of all, I disagree. My spelling is good but I rely heavily on spelling checkers to catch typos. They won't catch a typo that resulted in a valid word, but they sure help.
Second of all, even if I agreed it wouldn't be relevant. You're not likely to convince people to switch applications by telling them they shouldn't rely on a feature they've come to expect.
MS Word's grammar checker is useless. It's just plain wrong most of the time.
I use the grammar checker much as I use the spelling checker: To catch typing mistakes. Sure, most of its suggestions aren't great, but it will catch sentences where, in the course of rewording something, I ended up with two "the"s in a row or something.
See, but you're unusual: Most people aren't developers and don't use editors beyond things like Word and Notepad. For the average user those obstacles don't exist. I suspect that most users also aren't hard-core gamers (though there are presumably more gamers than developers:-p). My original point was about most users, who probably aren't tied to a particular platform by its software.
(And BTW, I think Visual Studio is a good app as well, though the WYSIWYG UI tool can be frustrating at times.)
Slashdot Mirror
If you're writing to the API, how tied to it are you? With a rederkit, you can quickly make changes from a web-browser to a PDA, with the components taking care of the display issues. Is display migration an issue?
I would argue that that's a dangerous approach: If you have a single UI for two platforms with radically different display sizes, it's liable to be difficult to use on one or both. Not necessarily true for sites and very simple apps, but as you get into complex applications I think it would be a problem.
Still, way better than what I thought the parent most meant. If Mail.app, in trying to display attached images, executed such a script, then you'd be in a position where you couldn't even view a message without risk. That might have been enough to cause me to switch to Thunderbird.
As it is, we Mac users just find ourselves needing the same vigilance as Windows users (which many of us probably exercise already) in making sure attachments are legitimate before we open them.
I tried this in Mail.app...even modified the script to create a file on my Desktop to be sure...but nothing happened. The JPG script showed up as a file attachment but apparently Mail.app didn't try to display it.
Hoping that means Mail.app isn't vulnerable after all...
I think I speak for many Mac users in saying that our smugness (which is never really a good thing) is derived from how much easier it is to be a Mac user these days in the face of all the Windows security threats. It's reinforced, too, by a deeper confusion regarding why so many people feel like they *have* to use Windows. I'm secure in recommending Macs as a more secure alternative - not because I believe that Macs are inherently immune to attack, but because today's reality is that they're at much lower risk, and no matter how much I plead with my friends and relatives they're not diligent about security.
And that's the real problem. I take security measures with my Mac. But many people don't want to learn about or take the time to implement security measures. Windows security would be a whole lot better if every Windows user upgraded to XP SP2, turned on Automatic Updates, and installed a firewall. Add anti-spyware, anti-virus, and a non-admin account and things look even better. Mac and Linux users, at the very least, should have firewalls and should be careful about what they download and run. But by and large, people don't want to bother. And given that, a system that (a) gets fewer attacks and (b) comes configured without root privileges seems like a clear winner to me.
The longer-term challenge is how to manufacture computers that are secure enough out of the box to survive without user intervention...because most users won't take the time.
Last time I looked at it, Mono didn't support Windows Forms (and thus couldn't just run your average .NET app out of the box). Has that changed?
I definitely don't think desktop applications represent the epitome of usability. However, I think the average Web application is worse. A basic Web site may be better, in part because it's simpler - text, hyperlinks, and basic form controls. (Though a surprising number of sites manage to screw up the Web's basic usability with hard-to-read text and links that are indistinguishable.)
But once you get into real application functionality, I think the Web is a dangerous place. While desktop apps aren't perfect, the APIs and pre-built UI controls mean that a novice to interaction design can still put together an app whose components have been usability tested and behave in a consistent, expected way. Right now, any complex UI controls in HTML must be built from scratch, resulting in some combination of inconsistency, poor usability, and poor functionality. To do otherwise is difficult to impossible: Few people are experts in both Web development and usability, and even those who are have no official or ad hoc standards to build on. Does it act like a desktop app? Like a Web site? Like something else? There's neither a technical nor a conceptual framework in place.
I hope you're right that server-side toolkits will alleviate these problems. That would certainly close a major gap, though as I think we both agree there are still significant disadvantages (functionally) to any app that runs inside a browser vs. desktop applications. However, the task of creating good server-side support isn't trivial; requires good UI designers; and to be fully effective must be somewhat consistent across server-side frameworks. I fear it may be a while; meanwhile, Macromedia created a set of standard widgets that, regardless of what else one might think of them, allow for consistency and predictability and don't require developers to keep reinventing the wheel.
I also maintain that Flash is a better option architecturally. Even with server-side frameworks that take care of the details, the HTML, JavaScript, and CSS combo seems like a messy way to construct a complex UI.
In the end, I suspect we both agree that neither Flash nor DHTML/AJAX is an ideal platform for application development. We just disagree about which is the lesser of available evils.
Of course, it is: the secret behind the web's success is the developers and the fact that HTML and HTTP made it easy for them to deliver content and applications, while keeping them from doing the stupid things they used to do when programming applications for the desktop.
I both agree and disagree with most of your points. Yes, HTML and (to a lesser extent) HTTP made developing for the Web easy. No, it didn't keep developers from doing stupid things akin to the stupid things they do on the desktop. People will always make bad apps and publish bad content on any platform.
You're quite right that web technologies make it hard to layer application-like functionality on top of the web, and that's a good thing. It keeps people like you from treating the web as a desktop application delivery platform. You can either adapt to that, or you can get a different job.
It should be a good thing, but it's not because technical and usability considerations tak e a back seat to business ones. I don't like Web applications, but it's all I end up designing these days. I can argue until I'm blue in the face that the Web is the wrong platform for app development, but people choose Web over desktop applications because neither a download nor an install is required. It's hard to argue with that logic, when consumers and IT departments alike are reluctant to install things on desktops. So Web apps flourish, despite their limitations, and the best we can do until there's a viable alternative is make the best of it. DHTML and AJAX help; but again, I'd argue Flash is a better choice because it's better suited architecturally.
Yes, OpenLaszlo delivers typical Flash applications: applications that don't support cut-and-paste, ignore browser font sizes or preferences or screen resolution, don't provide accessibility, don't resize properly, and have numerous other usability problems.
Sorry...I didn't mean to hold up OpenLaszlo apps as a shining example of good Flash applications, so much as to provide an example. Of what I'm not actually sure now that I think of it. I think it's a neat idea but it could certainly use some improvement.
Flash is technically OK for little animations, which is what it was originally designed for. But Flash is a lousy web-based desktop application delivery platform; Java, RDP, VNC, and X11 would be far better for that and far easier to both develop for and use. But, in fact, it has turned out that the entire concept of a web-based desktop application delivery platform is flawed, which is why all those other platforms failed to catch on for mainstream web use as well.
Java: People got burned by Java early on; otherwise I'd agree. I haven't done much Java development recently, so the problem with Java may very well be one of perception at this point. That doesn't mean it's not a problem though. Java applets also tend to load slowly into browsers.
RDP: I like RDP. It seems snappier than some of the alternatives. If there were a cross-platform implementation at the app level (instead of the screen level) it might be a viable alternative to Flash and HTML.
VNC: VNC has always seemed slower than RDP to me, though it is cross-platform. Otherwise the same comments apply.
X11: X11 is exactly what the Web application platform should be. It is unfortunate that the X client/server model isn't built into either Windows or Aqua. With beefed-up security and some other improvements it could be the answer, and I think it's funny that 20 years later we're building apps in a poor imitation of it.
But again, the problem is not whether any of these technologies is better but whether it's viable. Delivering applications in HTML or Flash (which is installed on most desktops at this point) fits no-install, no-download requirement. None of the other options does.
Well, the Back button wasn't in the list I was responding to, but as long as you bring it up, you can support the Back button in Flash. Take a look at http://www.slideshowpro.net/demo/demo_default.php# id=nature&num=2.
And incidentally, as you move from traditional Web sites into Web applications with DHTML and/or AJAX functionality, the Back button becomes a problem even without Flash, as the browser's stored history doesn't necessarily correspond to the user's concept of browse history. In some cases a Back function may not even be appropriate.
Flash breaks just about everything about the web that made the web successful in the first place: open standards, text-based representations, user control over rendering, cut-and-paste, and screen scraping.
This is a list of useful attributes for developers and a very small number of power users, not a list of things that made the Web successful. Also, Flash supports cut and paste.
What made the Web successful was first, the ability to get information out to people easily; and later, the ability to get applications out to people easily (particularly e-commerce). In the first category Flash doesn't often come into play, though particularly with Flash 8's font smoothing it might make for more readable content. In the second category Flash is arguable better suited as a platform than HTML. Even with technologies like DHTML and AJAX you're still layering application-like functionality on a page-based platform and it's awkward. As an earlier poster pointed out, the fact that Flash is used for some bad sites and animations doesn't mean it's a bad platform. Take a look at OpenLaszlo (http://openlaszlo.org/) for one example of an interesting open source, Flash-based Web application tool.
Monopolies make me nervous too, but let's not confuse the existence of a monopoly with the quality of the technology in question.
AJAX apps will replace numerous desktop apps, but not because they're better. Vendors distribute products as Web apps because of a distaste for installing things by IT departments. Not requiring an install on every desktop can mean the difference between getting a sale and not. AJAX allows this to be less of a compromise in user experience, which in turn translates to competitive advantage.
f rame.html) as well as a library called JSRS that works in v4.0 browsers (http://www.ashleyit.com/rs/jsrs/test.htm).
Even in the Web space, AJAX isn't actually better than anything: Flash is arguably a more appropriate rich application platform and can do everything AJAX can. Java is an even better application platform. But I think people got burned by client-side Java when it first appeared and are wary of it now. In addition, turning your Web app into a Flash or Java app requires significant retraining and recoding, while adding some AJAX does not. Thus AJAX is an easier path to a better product in many cases.
AJAX is also not a silver bullet for application functionality on the Web. For example, an AJAX-based word processor can't directly open and close documents on the user's hard drive. While the solution doesn't have to be local file access, the current state of affairs isn't enough I don't think. Also, Web apps are stuck inside a Web browser, which means limited acces to OS-wide features and unfortunate ties to a UI designed for pages, not apps. These aren't limitations to AJAX only, but to anything confined to a browser window.
For the promise of AJAX to be realized on a large scale, some things need to happen. Web app frameworks need to incorporate it more. This has already started to happen with Rails, JPSpan, and others, but the integration needs to be tighter and the standard enterprise development environments need to incorporate it. In addition, AJAX permits much more application-like functionality but the Web only natively supports some very basic user interface elements. A standard set of elements, available to everyone with a consistent look and feel, will both make building AJAX apps easier and make for a more consistent, predictable user experience Web-wide.
Last, it's worth noting that you can do AJAX in earlier browsers than those that support XMLHTTPRequest. It used to be called Remote Scripting, and there's an excellent article on the Apple developer site describing the technique (http://developer.apple.com/internet/webcontent/i
Not sure I agree. I suspect that most home users user whatever software came with their computers. Despite the ease of doing so, few even update with any particular frequency. So they'll buy a new Mac in a few years, it'll run on Intel, it'll have new versions of AppleWorks and iLife and iWork, maybe they'll buy a MS Office upgrade with it, and the transition won't really affect them.
Then there are those of us who just bought 2.5GHz Power Mac G5's and expected them to last 4 years while working with the latest software...
Hmm...sounds doable. I would need to learn more about RoR to understand the details, but one would think that between the Web server config and the Ror config you'd be able to pipe the RoR output through the XSLT processor before sending it to the client.
I'm a user interface designer, and as such do a lot of HTML-based interactive prototypes or mockups for Web apps. I've been using XSLT combined with XML sample data files: The XSLT allows me to build up XML-based widgets for complex but common elements and then quickly create pages using them. For that it's great, but it can be a bit cumbersome in other respects. So I'm wondering: Is there any way to integrate RoR and XSLT? Use Ruby on Rails for some of the back-end stuff but keep my XSLT widgets for the front end? Or, alternatively, is there some equivalent platform for my XSLT widgets in RoR?
Actually, a UI should be judged on both. The balance varies depending on the intended user. A UI that sacrificies efficiency for intuitiveness is fine if it will mostly see infrequent, novice use. But a UI that will be used constantly for complex or repetitive tasks might justify a steeper learning curve in exchange for greater efficiency (for example, less extraneous mousing around). In the best case one doesn't have to sacrifice one for the other, of course, but sometimes it's necessary.
So what's a good alternative for SMB in terms of sharing files among a bunch of machines, potentially running multiple OSes? My understanding is that FTP isn't the most secure protocol either.
What about WebDAV?
The "stop whining" approach is not going to help the GIMP supplant Photoshop.
Using a platform's window management to excuse any difficulties people are having with the product is not going to win over users. The platform is what the platform is, and for an app to be usable it must make the best of it. I hate MDI with a passion, but Windows has yet to produce a better answer to the Mac's global menu bar. If I were writing Photoshop for Windows I might use MDI too.
Responding to user complaints with things like "just set your windows up this way" or "just change these preferences" isn't a solution. I suspect the GIMP has lost and will continue to lose users who look at it, say "this doesn't measure up to Photoshop," and move on. The defaults cater to new users; advanced folks can customize.
I see several main UI advantages of Photoshop, comparing the Mac version (since that's what I use):
- The global menu bar works well in a graphics app, because means functions aren't somehow tied to a single window. With an open document I suppose that's not such a big deal, but even so I think it's cleaner.
- The palettes are smaller. The GIMP takes up a HUGE amount of space. I can't resize the toolbox down beyond 2 columns, and if I do that I lose most of the main app menus. The Small theme helps a little but doesn't really solve the problem. I don't think the GIMP is feasible to use at 1024x768.
- Photoshop palettes are more clearly secondary windows. They disappear when the app is in the background; they can be docked; their positions can be saved. This makes for easy window management without much effort. This type of functionality would serve the GIMP well.
Obviously there's more to developing the GIMP than cloning Photoshop. But there are distinct advantages to cloning Photoshop: People like it; it makes transitioning to the GIMP easier; and Adobe has put a lot of thought into Photoshop, so presumably there are good reasons for many aspects of its interface and feature set.
My reaction to the book was simular to yours. The idea that captured my imagination the most was the concept of getting rid of applications all together and creating a system architecture based on documents and tools that operate on those documents. There are so many aspects of this idea that would cause it to be a very powerfull and flexible system.
It does seem like a good idea. And actually, Apple tried it with OpenDoc. OpenDoc's failure may not mean the idea is bad, though. But I do question it a little. Seems like we do work in the physical world based on concepts of documents and of tools, i.e. "that note I'm writing" and "the pencil I'm writing it with." Which is more important? What's an appropriate way of relating the two? I don't know. I'd like to see some good research on it.
One of his axioms was that you should never have to manually save a file, that it continuously trickles the changes you made to disk, as you make them.
I agree with his axiom, but I don't think it requires a different way of doing things. There are multiple ways it could be implemented without eliminating filenames (a rather simple one might be a "New Documents" folder on your desktop, but I'm sure one could do better). Not to say we shouldn't investigate, but without further evidence I don't think we should simply discard the possibility that names for things are useful.
I agree with your concerns about ZUIs. I've used and even designed for ZUIs and I think they can be very compelling, and are useful in a number of situations because of how well they represent a hierarchy and provide feedback for its relationships. However, the issues you cite seem reasonable and aren't something I recall Raskin addressing. I'd like to see this use of the ZUI addressed by thorough empirical testing.
It is interesting that so many UI experts are of the opinion that filenames and directories are a complete failure for the average user. All the people that I know organize their files just fine this way. I need to get around to reading the studies that cause them to feel this way.
I won't be so arrogant as to claim to be a UI expert, but I do do UI design for a living, and I'm not at all convinced that files and directories are a complete failure. I can think of some issues in their representation, but that doesn't mean we should toss them out. I, too, would like to see some research evaluating their effectiveness.
Interesting. Ultimately though, the question is not, "Do I use hierarchies?" or "Do you use search?" but:
- Do people naturally use one or the other, a combination of both, or something else?
- What combination of structures and information-finding mechanisms will best serve users?
- What is the best balance between variety and simplicity?
I've also read his book, and found it alternately worthwhile and very frustrating. A lot of the basic principles he talks about -- such as the issues of modality mentioned by the previous poster -- are important, well-supported, and can in some cases be implemented within the current GUI framework.
However, he goes on to design what he calls the Humane Interface, and suddenly many of his arguments are based on sweeping statements that I have trouble taking at face value and that aren't well-supported. For example, he proposes doing away with folders, filenames, and indeed separate files altogether and allowing users to find whatever they need via an incremental search of their disks. Incremental search is useful, but I have trouble believing that most users would be able to remember the content, let alone the exact wording, of every document they wrote. I certainly find things myself according to where I put them (i.e. what folder, sub-folder, etc.).
For users who like hierarchies (who he feels are few), he proposes a system of pages, documents, and folders based on various numbers of page breaks. (Two for a document boundary, 3 for a folder boundary, etc.) To me this seems like shifting the burden of maintaining a filesystem onto the user to create the technical simplicity of a single document, and without empirical evidence I have trouble believing it's a good idea.
He goes on to add a zooming user interface to his system. I like ZUIs and think they're a neat way to browse hierarchies. But in the preceding chapters he has done away with hierarchical structure, and thus in adding a ZUI he is effectively adding a dual structure to his filesystem. Again, this seems to be increasing the burden on users' minds by asking them to track two parallel structures to their data.
As has already been pointed out by others, it also seems a bit odd that, in the end, so much of his book is devoted to scrapping the GUI in favor of something similar to the Canon Cat.
I agree with most of what Mr. Raskin has to say in this interview. Computers are inefficient and bloated. (I think the 1000-page manual example is a bad one, since the existence of numerous features is not in itself a problem for users uninterested in them.) User interfaces can be easier to learn and more efficient. Modern operating systems are converging on a GUI standard, which is great for cross-platform use but isn't pushing user interface innovation forward. In all these things he's dead on, and certainly not alone. But he seems to think he's found the answer, and I question whether he really has.
You are both right and wrong. "Ease of use" is a deceptively simple term that encompasses a number of important things including how easy a product is to learn; how efficiently an experienced user can use it; and how quickly an inexperienced user can become an experienced user. The new users who will have the hardest time are often those who are used to a similar product. Sometimes designers have to trade off these various factors against one another. But they're all worth considering and certainly a product can be better or worse in any category. You may get used to one OS or another over time, but that doesn't mean you'll be equally efficient using each, or that each will take the same amount of time to adapt to.
Actually, my impression is that Windows users aren't biased towards MS. They just have the impression that they have no choice. I think it sometimes makes them _harder_ to convince.
Overall, the multitude of distributions is a good thing. Every distro is designed with slightly different goals (and created with different skills), increasing the chances that a given person will find a distro that suits him. The fact that many distros are variants on a much smaller number of "base" distributions increases that, since it gives distro creators the chance to choose an already-stable OS and tweak and/or improve upon it.
However, there's one major drawback when it comes to adoption of Linux by new users. If I'm a Windows user looking to switch to Linux, I will quickly discover that "Linux" is in fact a large number of slightly different operating systems, and the task of switching to it may suddenly become extremely daunting. I hope that with time, this sorts itself out and the choice for novices becomes easier...I think it will.
BTW, I've installed Ubuntu on both a Powerbook and a Dell P4 without a hitch. Easy installation, easy to use. I like Fedora's customized Gnome layout and theme a bit better (and think it's a bit more usable), but good stuff nonetheless, and especially nice to have an easy-to-install, up-to-date distro for PPC.
Yeah...as I said I don't use it for actual grammar, just as a handy double-check on typing and editing errors.
Perhaps if they added a "Hide stupid suggestions" checkbox in the grammar options that would help. It would definitely improve my opinion of MS...
First of all, I disagree. My spelling is good but I rely heavily on spelling checkers to catch typos. They won't catch a typo that resulted in a valid word, but they sure help.
Second of all, even if I agreed it wouldn't be relevant. You're not likely to convince people to switch applications by telling them they shouldn't rely on a feature they've come to expect.
I use the grammar checker much as I use the spelling checker: To catch typing mistakes. Sure, most of its suggestions aren't great, but it will catch sentences where, in the course of rewording something, I ended up with two "the"s in a row or something.
See, but you're unusual: Most people aren't developers and don't use editors beyond things like Word and Notepad. For the average user those obstacles don't exist. I suspect that most users also aren't hard-core gamers (though there are presumably more gamers than developers :-p). My original point was about most users, who probably aren't tied to a particular platform by its software.
(And BTW, I think Visual Studio is a good app as well, though the WYSIWYG UI tool can be frustrating at times.)