The “why” of Ruby on Rails comes down to productivity, says Michael Slater. Web applications that share three characteristics—they’re database-driven, they’re new, and they have needs not well met by a typical CMS—can be built much more quickly with Ruby on Rails than with PHP, .NET, or Java, once the investment required to learn Rails has been made. Does your web app fall within the RoR “sweet spot?”
The “how” of Ruby on Rails: Hivelogic’s Dan Benjamin prepares non-Rails developers, designers, and other creative professionals for their first foray into Rails. Learn what Ruby on Rails is (and isn’t), and where it fits into the spectrum of web development and design. See through the myths surrounding this powerful young platform, and learn how to approach working with it.
If “Our Broken Borders” should someday turn into a ratings loser for CNN’s Lou Dobbs, perhaps he can switch to “The Dwindling Productivity of the American Worker: Is Facebook Sapping Our National Vigor?”
Like comic books, rock and roll, heavy metal, gangsta rap, gaming, and MySpace, the web is no longer an easy card for parent-scaring pundits and politicians to play. But social networking sites AKA community-focused web applications AKA “web 2.0” can still be blamed for a variety of social ills. That they are actually blameless doesn’t matter. The truth never matters in this game.
And since it’s easier to say “Facebook” than “the aggregate of new social networking sites and applications such as Flickr and Twitter,” there’s every chance that Facebook will take the whipping for the entire category.
That this will actually increase Facebook’s market value is known but won’t matter to the people who pretend to be outraged about “the Facebook generation” or “social not-working” or whatever the pundits end up calling the “crisis.”
The same thing happened when religious authorities tried to ban “Carnal Knowledge,” “The Exorcist,” “Hail Mary,” and “The Last Temptation of Christ.” In every case, people who otherwise wouldn’t have bought tickets for these films, showed up, lined up, and even bought popcorn.
At least “The Exorcist” was entertaining.
And of course, parental outrage and the PMRC have sold plenty of rap and metal.
If Facebook, Twitter, and other social networking apps get boosted by fake outrage, they’ll acquire more investors. And they’ll need them, since all these applications run at a loss, and all of them suffer from terrible scaling problems.
The scaling problems will grow worse as the apps become more popular; investors will buy smaller and smaller pieces of a less and less viable business concern; and when it pops, we’ll be back to the bird flu movie of the week.
So the planet warms and the Kenyans kill their neighbors and we tweet about nothing and hope the servers hold out.
I’m afraid this is another of those entries outlining bizarre design decisions and perplexing usability quirks in the otherwise brilliant world of Apple computers and phones. The problem is sync. It can be done, but it often goes wrong, even for smart people who understand computers, haven’t hacked their equipment or broken the law, and are kind to dogs, cats, and children.
Here’s a particular setup: .Mac account. Tiger laptop at home, Leopard iMac at office.
On both Macs, you need to refresh your subscriptions (Calendar: Refresh All) before you sync for the first time at that location. Otherwise, sync deletes the subscribed calendars’ information. Just wipes it clean away.
And even if you Refresh All first, sync may wipe away your data, just because.
Fortunately, after sync erases your data, hitting Calendar: Refresh All again reinstates it, downloading saved data from .Mac.
Why does syncing on either Mac remove all the calendar events from subscribed calendars? It’s the opposite of what any user could possibly want. There’s not even a conceivable edge case where a user would expect “sync” to mean “I’m bored with my life. Surprise me. Make my calendar data disappear.”
One doesn’t sync to lose data. Losing data by syncing is the exact opposite of what a user expects—which also makes it the opposite of what the Macintosh experience promises and usually delivers.
.Mac sync is either partly broken; or correctly designed, but to absurdly limited scenarios; or designed so counter to a user’s expectations that it should only be run with instructions, which Apple does not provide.
Apple does not provide instructions because instructions imply a learning curve, and Apple’s pitch is that its stuff just works. One nevertheless expects at least a slight learning curve when using, say, GarageBand or Keynote. But not with sync. “Sync now” seems pretty self-explanatory, and no user doubts what’s supposed to happen.
Sync does give you a warning before dumping your data, and that warning provides a clue to what’s going wrong. It tells you that syncing will remove x number of items from your calendars, and even lists which items they are. In Leopard, it goes further, and shows you before/after views of items that will change.
Significantly, there is generally no change at all between the before and after views. Probably the “change” is to a part of the database that the user doesn’t see, and has to do with differing file formats or differing time-stamp conventions between Tiger and Leopard. A less buggy or better conceived interface would hide this non-information from the user instead of asking her to think about it.
Do I really need to see that “Lunch with Jim at 1:00” is going to “change” to “Lunch with Jim at 1:00?” Probably not, since, from my perspective as a human, the two items are identical. It’s lunch. With Jim. At 1:00.
If “Lunch with Jim at 1:00” is “different” from “Lunch with Jim at 1:00” to my Macintosh because Leopard and Tiger encode or store calendar items differently, or because Leopard and Tiger time-stamp event creation dates differently, that’s not information I need to know and it’s not a before/after view I need to see.
Before/after seems cool, and probably is if your data is actually changing. For instance, if you’ve changed one of your friend’s photos, it would be nice to compare the before and after views and decide which photo you prefer. But I’ve never seen before/after work that way. Changed photos just get changed. Before/after only seems to come into play on my networks when “Lunch with Jim at 1:00” is changing to “Lunch with Jim at 1:00.”
The irrelevancies I’ve just described must be endured, and the sequence (Refresh: All, then Sync, then Refresh: All again if data was lost during sync) must be performed in the order described, before syncing the iPhone. If, in a moment of derangement, you plop your iPhone onto its dock before doing the herky-jerky data dance I’ve just described, you will lose data not only from your iPhone, but also from .Mac, and then you will never get your data back.
Your mileage may vary.
There are always 100 people for whom everything works correctly, and some of them are always moved to tell me it works for them, and to imply that I’m somehow to blame for the obvious usability problems I’m clearly describing.
They are followed by a dozen Apple haters who want to believe that the lengthy and detailed description of a specific usability problem proves Apple makes bad products, and anyone who claims to enjoy using Apple’s hardware and software is a “fanboy.” Juvenile homophobic and misogynist name-calling often accompanies these messages of hope.
Here’s what I am actually saying.
On my two-Mac setup where one is on Tiger and the other on Leopard, I can make sync work, but I must carry out actions in exact sequences, and know the tricks to undo the damage that syncing inflicts on my data due to bizarre design decisions on Apple’s part.
A few times I have irretrievably lost data, although I was able to manually recreate it by emailing colleagues and asking, “When are we meeting?”
It reminds me of running an old analog mixing board in a dirty, smoky recording studio. Everything’s cool if you know which faders you must never touch, which inputs are dead, and how far to the left you can pan a sound source before shorting out the system.
There’s genius in the concept of sync, and it works magnificently when you’re, for instance, syncing just one iPod to just one Macintosh, always the same iPod and Macintosh.
It gets weird when syncing from home to office via .Mac across operating systems, and weirder when you throw hot iPhone action in.
How should sync work? Just like you think it should work. Just like the two arrows circling in on each other (sync’s icon) imply that it does work. Hitting sync at any time on any networked device should cause all the latest changes to be stored on .Mac and downloaded back to whichever connected device you’re using.
There’s a whole other discussion to be had on why the iPhone is supposed to sync to only one machine, (Sure, iPods do that because of DRM restrictions; but competitive PDAs can sync to any computer: home, office, you name it. Likewise with digital cameras. The iPhone is a phone, an iPod, a digital camera, and a PDA, but its syncs like an iPod, not like a digital camera or PDA, and that’s just dumb.) but we’ll save that one for a rainy day.
Sync long and prosper.
Addendum: Another crazy thing is that subscribed iCals from Basecamp don’t update upon refresh in Leopard. In iCal in Tiger, subscribed Basecamp iCals correctly refresh automatically when one selects Calendars: Refresh All. But in iCal in Leopard, subscribed Basecamp iCals do not refresh, period, no matter what one does. In order to “sync” Basecamp iCals in Leopard, one must delete the calendars every day, and subscribe to fresh copies. When one does this, one gets fresh calendar data, but sync fails due to “conflicts” that do not load in the frozen Conflict Resolver and thus cannot be resolved. This of course is not what Apple intended. It is, by any reasonable measure, an idiotic and self-defeating system. The basest ape would not design such a system. Obviously the system is not operating the way Apple intended. How does one fix it? Apple isn’t telling.
Comments are now off, but you can read what others had to say when comments were open.
Installed Tiger update 10.4.11 this morning, which mainly provides Safari 3, which cannot access web content. It quits on launch every time.
I have no unsanity products installed, and no APE in my library, but I see “smart crash reports” by com.unsanity.smartcrashreports in the system info Apple collects prior to sending itself a crash report every time Safari 3 quits (which is every time it launches).
At some point in the past, I bought an unsanity product which I later uninstalled—but apparently there is a still a piece of their stuff around somewhere. This may or may not be causing Safari to eat its head.
Great time to break out the latest version of Camino.
A few days ago, Douglas Vos of Dearborn, Michigan, created a Designing With Web Standards group in Facebook just to see what would happen. Don’t get me wrong: It’s not like he started a group about moss formations or watching paint dry. Doug has read both editions of the book twice, and is a big fan of standards-based design. He started the group because he was interested in web standards and he wanted to understand, from the inside, how such groups function and grow in Facebook.
At this moment, the group has 422 1,142 members, seven wall posts, eleven discussion topics, three photos, one video, and two links. I wrote a post there today about my upcoming web standards talk at BusinessWeek.
I am curious whether the new group will become a passive affinity group or something more.
By passive affinity group, I mean the kind of group people join to show they belong—and then don’t do much, if anything, once they’ve joined. For instance, hundreds of thousands of people joined a Facebook group in support of the monks’ protest in Burma. Everyone who joined supports free speech and democracy, but only a tiny handful of group members create content or begin initiatives. For the few who are active, membership in the Burmese monk support group is an act of political and spiritual engagement. But for most members, it’s passive. This is true of all social groups (online and off) and nearly all human activities.
If people who incorporate web standards in their work join the DWWS Facebook group as an act of affinity, that’s fine and dandy, and it will be in some small way a measure of the progress of web standards as a movement or discipline. But the group could do more. Much more.
For instance, the group could track large-scale conversions to web standards and accessibility among corporate or government websites. It could also track backsliding, such as the infamous British Disney site, redesigned for standards compliance and accessibility by Andy Clarke at the beginning of the 2000s, and then redesigned back to tables and cruft by a successor web agency.
The group could track which schools and universities are using Designing With Web Standards and other “web standards” texts in their design or web curricula.
The Web Standards Project used to keep track of such things when I was running it, and I used to keep track of them here, as well; but I can’t do it any more, and The Web Standards Project doesn’t seem to be doing it either (probably because The WaSP is busy with other activities).
Maybe that’s where you come in.
It’s just a group on Facebook, but it could do some good.
[tags]dwws, designing with web standards, facebook, zeldman, books[/tags]
The Joy of Technology
Good morning. Twitter, Facebook, iLike, and Word have imploded. After going offline for improvements, Twitter shows my previous custom background instead of my current choice. Random user preference rollbacks aside, at least Twitter still works. In fact it seems peppier.
Meantime, iLike in Facebook no longer shows live playlists now that iLike has officially made it possible to merge the two accounts. Playlists worked in Facebook before the announcement. (Before, iLike’s FAQ said it was impossible to merge the two accounts; but it was possible and worked well. Then iLike announced that you could at last merge the two accounts, and a nervous engineer apparently changed a setting, breaking the linkage.)
Not to be outdone by upstart web apps, Microsoft Word quits when I edit a document, and none of the standard fixes help. Word has not been updated for the Macintosh for years, of course, and it runs in emulation on Intel Macs, but I am used to that. Updating the Normal template was the last thing I did before Word started eating its own head.
Mmm, that’s good coffee.
It goes without saying that I’m editing documents of some importance.
If I open the documents in Pages, Pages posts a “Can’t find spell checker” error box. When I close the error box, Pages posts it again. When I close it again, Pages opens it again. This loop continues beyond Armageddon.
If I edit the documents in TextEdit, I can’t format them correctly, and Word’s non-standard hyperlink formatting turns nightmarish.
Third sip of coffee. Just another day at the office.
[tags]twitter, facebook, ilike, ilike.com, webapps, socialsoftware, word, microsoftword, microsoftoffice[/tags]
Facebook Considered Harmless
IN 1995, I RECKONED everyone would teach themselves HTML and start homesteading on the web. When that didn’t happen, I spent three years on a free tutorial I figured would give the world the push it needed. It didn’t.
I was an early blogger and a late user of blogging software because, why did anybody need blogging software? Wrong. Always wrong.
In 2004, some colleagues and I contributed to the “new” Blogger. We were excited by the thought of bringing well-designed, easy-peasy, standards-compliant web publishing tools to millions of people. Now everyone can do this, we thought. And millions did.
But not everyone, it turns out, wants to blog. Blogging is hard. There’s, like, thoughts and stuff that you have to come up with, even if someone else handles the whole “what should my blog be like and what should it do and how should it be organized and what should it look like” part.
No, what most people were really looking for—or at least, what most people have responded to since such things became available—were web gizmos as easy as farting and as addictive as cigarettes. “Social software.” “Web 2.0.” Swimming pools, movie stars.
All this to preface the unremarkable yet strange to those who know me fact that yesterday I signed up for Facebook. And spent several hours messing with it. And checked it this morning before making coffee, before making breakfast for The Wife and I, before bringing The Child her strawberry milk.
Facebook is pretty. It works with Ma.gnolia. It works with Twitter. In theory it works with iLike, except that you can’t add an existing iLike account to Facebook, which is lame and sucks and iLike’s fault, and the fact that I care and am bothering to share such trivia shows how deeply assimilated I have become over the past 24 hours, eight of which I spent sleeping.
As when I joined Twitter, the first thing I noticed was how many of my friends and colleagues were already there ahead of me. Why none of them had invited me to join, bastards, I leave to their consciences, not that I’m bitter. They redeemed themselves by responding within an hour or less when I asked to be their “friends,” not that I’m keeping score.
I don’t need more friends and I don’t need more contacts. I avoided most of the first-generation social software that was all about Rolodex building, and only gave in to the main one everyone knows and which I shall not name when a loved old client of mine invited me to join his network. Since I made that mistake, I get lots more mail, and lots more mail is something else I don’t need.
But I design interfaces so I’m supposed to know about this stuff. That’s the rationale behind my spending hours of billable time adjusting my Facebook preferences. The real reason, of course, for all this stuff, is that it provides a way to blow off work you should be doing, while creating the illusion that you are achieving something. At least in most offices, you can’t masturbate at your desk. But you can Tweet.
In Issue No. 245 of A List Apart, for people who make websites: Sarah B. Nelson of Adaptive Path shows how to create collaborative work sessions that actually work, and Iconfactory’s Craig Hockenberry concludes his remarkable two-part series on designing and coding with the iPhone and its new brethren in mind.