Mon, Jan 4, 2010 11:20 AM
Would you be so kind as to email me a copy of your birth certificate and all of your credit card numbers along with the security codes from the back?
Sure, most of you don't know me, and with that info there's no end of damage I could do to you. But at least I'm asking politely, and isn't that enough to earn your trust?
Of course this is an absurd request, but think about it: when you deploy a Revlet on a public site that tells the user it needs access to their hard drive, is it all that much different?
Will your Revlet be reading files from my drive and sending them to your server? Will it install trojan horses? What exactly does it need to do that requires access to my drive?
A surprising number of Revlets I've come across ask me for access to my drive, probably more than half of them.
I've asked a few of the developers of those Revlets why their app requires access to the user's hard drive, and in most cases it's for trivial things like storing preferences.
RunRev's free browser plugin is a wonderful opportunity for deployment, but using it to deliver a great browser experience requires that we recognize it's more than just a way to deliver our stacks without having to download the engine.
If it's in the browser, it's a very different experience altogether, one that suggests we rethink even common things like preferences in ways that make good use of the web.
Any new plugin will be compared to Flash, the de facto standard which has been bundled with every major browser release for at least a decade.
Flash developers rarely rely on locally-stored prefs. Why should they? Cookies can be used to store small amounts of data, and for anything larger the cookie can reference a database record for the individual user stored on the server.
If you're going to use the web, use the web.
If there's a benefit to liberating your users from needing to install a desktop app, liberate them fully and leave their hard drive alone whenever you can.
Sure, there may be some sophisticated Revlet applications which can and perhaps should make good use of the user's drive. But such potentially-dangerous local access should be relied on sparingly, perhaps only in educational or other organizations where you've already established some trust with the end-user.
When we publish stacks for the general public we really need to slow down and ask ourselves:
"Is it truly necessary to have access to the user's drive?"
"Will this turn people off to my work?"
"With this turn people off to Rev?"
For RevWeb to be adopted, we need to do our best to make folks comfortable running stacks with it. If we get lazy and just rely on local storage for even simple things like prefs and high scores, we risk scaring them off, leaving them with the impression that RevWeb is a dangerous thing.
The warning dialogs are a very useful part of the RevWeb experience. Let's make them more useful by using them sparingly, avoiding them completely whenever possible.
Blog Home Filed under: usability marketing
|
Richard Gaskin
Ambassador, Fourth World
Netbook market on the rise
RunRev Complies with Jobs' Request, Moves Toward Android
Apple Snubs OS X at WWDC
Moment of Zen
Apple's new SDK license locks iPhone out of the HLL revolution
Scripting Style Guide Updated
Agile Manifesto
Bugs in Rev: a little perspective
New Rev-centric Linux Distro
Crystal ball time
Too tall to live, too weird to die
Oracle, Sun, and the future of MySQL
RevWeb security warnings: use sparingly
Installers making a comeback on Mac?
"Rev Message Path" article updated
Your Windows 7 Launch Party
Smartphone competition - at last
Benchmarking performance
New Interviews at revJournal: Jerry and Andre
Windows 7 HIG: time to say goodbye to XP?
agile (1)
Apple weirdness (2)
best practices (2)
community (1)
databases (1)
fluff (2)
games (2)
HyperCard (1)
iPad (3)
iPhone (1)
irony (1)
linux (1)
marketing (6)
mobile (1)
netbooks (1)
performance (1)
predictions (1)
rant (2)
RevMobile (1)
RunRev FAQ (5)
scripting style (1)
server (1)
UI (1)
usability (6)
RunRev.com
Sarah's Rev Blog
Björnke's Stacks Blog
theWorcesterSource
Releasable Rev Blog
RevEditor (tRev) Blog
Chipp Walters 'Rev Blog
WeCode Planet
|
