Topic Archive: Safari

Four blatant iPhone usability blunders (and one constant annoyance)

Brian Dillard, Thursday, September 4, 2008 @ 12:14 pm

I've been an iPhone 3G owner for about six weeks now - six weeks of love, loathing, cool apps and connectivity problems. Rather than complain about poor network coverage, though, I'd like to delve into some of the vexing usability problems that hamper the phone's user experience.

No ability to disable autocorrect completely

Like pretty much every autocorrect feature ever built, the iPhone's does more harm than good. It always thinks it knows best. If you don't watch it like a hawk, it will render everything you type completely nonsensical. Proper nouns, abbreviations, profanity - all get turned into gibberish by this well-meaning but deeply flawed function. And god forbid you try to use the classic email e.e. cummings mode in which uppercase letters don't exist. The iPhone literally will not let you output the word "iPhone" without throwing in that capital "P." It's maddening.

If the purpose of autocorrect is to allow you to type quickly without having to monitor your output, it fails miserably. On the iPhone, if you want what you type to show up verbatim on the screen, you have to pause at the end of each word to ensure that the OS is not about to substitute its own wisdom for your actual intent. I would honestly rather type on a 1999-era StarTAC numeric keypad.

None of this would be as galling if there were a setting to turn this feature off. But there isn't. Elaborate, unwieldy workarounds have been suggested - all because Apple users know that the folks in Cupertino often paternalistically ignore their users. Microsoft's OS and apps may suck, but you can usually customize the hell out of them. Not so Apple's.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (7)

agile ajax

Developer’s Notebook: Find computed styles in IE, Firefox, Opera or Safari

Brian Dillard, Monday, May 5, 2008 @ 3:58 pm

At my recent Web 2.0 Expo talk, I exhorted developers to get comfortable outside the Firebug/Firefox safety zone. By rotating between Opera, Safari and even IE as our primary development environments, we can really get to know those browsers - and perhaps learn to utilize their non-standard features. Switching things up, however, can inhibit productivity until you learn your way around each browser's tools.

To that end, I offer these step-by-step instructions for finding computed styles in all four A-grade browsers. I chose the display of computed styles as my "debuggers are cool" use case because it's an obscure but useful feature for CSS debugging. Most of the time I can debug styles by looking at my debugger's snapshot of the current cascade for a given element. But sometimes that's not enough. If I've assigned a value of "inherit" to the font-family of an element, then the cascade snapshot won't tell me what font is actually applied to that element. (Not being a designer, I often can't tell the difference between various sans-serif faces, especially at small sizes.) Luckily, computed styles can give me the information I need.

As these examples demonstrate, debugging tools have come a long way in the last couple of years. Let's make the most of them for all of our UI-layer needs.

Internet Explorer 8 and DebugBar

500

IE's JavaScript debugging tools have finally matured, but its CSS ones lag behind. Even IE8, with its built-in debuggers (under Tools > Developer Tools), won't show you computed styles. Luckily, Jean-Fabrice Rabaute has crafted DebugBar, an plugin for Internet Explorer 5+ that adds all sorts of useful tools. Install DebugBar, fire up your version of IE and choose View > Toolbars > DebugBar to make the plugin visible. Then click the "DebugBar" icon in the resulting toolbar to open the DebugBar sidebar. You'll see two tabbed panes, one below the other. Choose the "DOM" tab on top and the "Comp. Style" tab on the bottom. In the upper pane, you should see a target icon with the caption "Drag target on document to find element." Drag the icon anywhere on an open web page and you'll see computed styles for the corresponding element in the bottom pane of the sidebar.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

More on Safari and the new Gmail upgrade

Brian Dillard, Tuesday, November 6, 2007 @ 9:26 am

Over the weekend my Gmail finally got upgraded to the new version. (I know, I know, a week is hardly a long time to wait for a slow-rollout Google feature. But I'm impatient.) I have to say, the history and back-button support is AWESOME. It's funny that Gmail warns you in a huge red banner to disable Firebug. I, of course, kept it enabled and immediately began digging through the DOM of the new UI. As usual, most of the JavaScript is so obfusticated that it's hard to tell what's going on. Still, it's interesting to dig through layers and layers of iframes and nested divs and see how much DOM hackery is involved. Looking behind the scenes at any commercial-grade webapp is like taking a tour of a sausage factory.

Luckily, I have a strong stomach. I'm going to make it a weekend project to really dig in and learn how they're handling their history support. In a previous post, I wondered why the new Gmail is only available for Firefox 2 and Internet Explorer 7. Given my own experiences with Safari's history object, I shouldn't be surprised. With bookmarkable URLs and history management so central to the new Gmail UI, no wonder Safari has been left in the cold; it's simply too buggy in this regard to receive A-grade support. Safari users have been complaining to Google that it should fix Gmail for Safari even with the old UI. I think those complaints should be lodged at Apple, not Google.

P.S. Sure enough, leave Firebug open in Gmail for any length of time and your Firefox will slow to a crawl. My FF has been crashing a bunch this week, but I'm not sure whether it's Gmail or Firefox's own latest updates. Commenters, am I the only one seeing this?

• Gmail
• Google
• Safari
• Firebug

• Digg
• Reddit
• del.icio.us

Comments (8)

agile ajax

Coming soon: Really Simple History 0.6 beta

Brian Dillard, Tuesday, October 23, 2007 @ 1:24 pm

Late tonight over at Google Code, I'll be posting a beta of Really Simple History 0.6 for testing. The goal is to elicit help from RSH users in chasing down any bugs I've failed to catch, then push out a stable release around Halloween.

I've tried to be as ambitious as possible with this release: full support of IE7/Win, Safari/Win, Safari/Mac, Opera/Win, Opera/Mac. I've didn't quite get there, but I got close.

Features in the new version include:

• Full support for IE7/Windows (though my only Windows machines use IE7 Standalone, so I need help testing on "real" IE7 installs).
• Full support for Safari 2/Mac (though I'm still trying to eliminate the "infinite loading" bug before I push out the beta).
• Partial support for Safari 3/Windows (hampered by bugs in the current beta version of the browser).
• Full support for cross-platform Opera 9.22 (though you may need to hard-code an image into your markup).
• A totally revamped test page that allows you to play with the library in your browser of choice and see how it works behind the scenes.

As always, RSH works beautifully in Firefox 2 for Windows and the Mac. I hope to give it a good shakedown on Linux browsers in the next release.

So what is Really Simple History, and why am I updating it?

An Ajax bookmarking and history-management framework originally developed by Brad Neuberg, RSH became my responsibility a little over a month ago. I tinkered with it for a few weeks, then finally camped out with it for most of the past week to get a release out.

This is the first time I've ever contributed in this manner to an open-source project. It's been a lot of fun, but it's also been maddening, as anybody who's ever dug into the bowels of cross-browser history management can tell you. Here's a sampling of what I've learned from RSH:

Safari is crazy

Plenty of people who've worked on Ajax bookmarking projects have commented about this, but it only becomes clear once you've actually seen it in action. Getting this thing to work in Safari 2 for the Mac took a wildly disproportionate amount of time considering its market share. I wouldn't have been able to do it without Bertrand Le Roy over at Microsoft, whose blog entry on the development of the .Net history manager pointed the way for both Safari and Opera.

As Le Roy and others have noted, the Safari 3 Windows beta is so buggy that history management is hopeless. You can enable the back button for Ajax apps, but once you use it, the forward button becomes disabled. I noticed yet another wrinkle in this behavior (skip ahead if you're easily bored):

Navigate to a non-RSH site - Google, for instance. Then travel to an RSH site, create some history entries via RSH, and use your back button. The forward button stops working: a known bug. Now keep hitting back until you get back to Google again. Suddenly, your forward button works again. Hit forward and land back in your RSH app. Magically, the forward button continues to work.

If I hadn't spent so much of the last week lost in Safari-land, this interesting behavior might be worth further investigation. For now, I'm just hoping the Safari 3 team fixes this before the final Windows release.

Don't try to retire document.write just yet

A couple of different RSH users suggested getting rid of Brad's original calls to document.write in favor of standard DOM methods for adding elements to your page. That approach worked for some elements, but not for others.

In IE, RSH writes a hidden iframe into the document and uses the location and history of that iframe to help it track application state. Writing the iframe with document.createElement works just great.

But for all browsers, RSH uses a hidden textarea to store the entire history stack behind the scenes. This powers one of RSH's coolest features: its ability to retain history even if you navigate away to another site and then come back to your RSH application. This works because modern browsers retain form-field values throughout an entire browser session. But they do so only for form fields that exist in the DOM natively - that is, exist in the actual HTML markup or get inserted via document.write get inserted into the DOM before it's finished loading. 

If you create a form element after your DOM is already loaded, the browser has no way to persist values in that element after you leave the page. Each time the page loads, even from the cache, you essentially create a virgin new form field. I'm therefore using document.write for the hidden textarea - and for the hidden form field I've added to RSH for Safari support.

UPDATE: As it turns out, it's immaterial whether you use DOM methods or document.write. The important thing is to use either method before onload fires. I ended up using document.write in the 0.6 beta because of SSH concerns and the fact that it's so much more concise. For more on this topic, see this subsequent post. 

Because of the way RSH is structured, these elements actually get written to the head rather than the body of your document. Still, it works, and it should only offend the most anal-retentive of standards geeks. After all, if you're hacking the browser 10 different ways from Sunday just to enable Ajax bookmarking, then inserting a bit of non-validating markup via JavaScript is hardly the worst of your sins.

RSH won't be hitching its wagon to [insert name of your favorite framework here]

A few users suggested rewriting RSH in Prototype so it would be more compact. I appreciate the impulse, but I think that defeats one of RSH's chief virtues: the fact that it's written in Plain Old JavaScript and doesn't lock you into any specific Ajax framework. It plays well with any library you want it to: Prototype, jQuery, YUI, whatever. (If it doesn't, please file a bug so I can find out why.)

A little JSON never hurt anyone

The one library that RSH does require is a JSON parser; it ships with the latest open-source version. RSH 0.4 included an earlier version of the parser in the same file as its native code; I've broken it into a separate file under the logic that many users will already be serving a similar library. RSH's methods don't actually call toJSONString or parseJSON directly; instead, I've provided bridges so that you can hack in your own JSON methods without having to modify the guts of RSH itself.

Future roadmap

I've got quite a punch list for the next release:

• Provide minified versions of RSH and JSON for download
• Make use of Crockford's module pattern for better encapsulation
• Add official support for Linux browsers, Safari 3/Mac and Safari 3/Win

That's the future. For now, I have to get 0.6 packaged up and ready for testing. Check Google Code late this evening or first thing tomorrow.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Really Simple History: Onwards and upwards

Brian Dillard, Wednesday, September 12, 2007 @ 5:25 am

I'm excited to announce that I've heard the call and volunteered to tackle maintenance and stewardship of Really Simple History, Brad Neuberg's intuitive, lightweight Ajax history library. Brad developed RSH a couple of years ago, drawing inspiration from the Dojo Toolkit folks to deliver a standalone library that provides back-button and bookmarking support for Ajax apps in IE6 and various Gecko-based browsers. Since, then, many additional Ajax frameworks have implemented back-button and bookmark support, some of them drawing on Brad's work.

Meanwhile, Brad's been too busy with other projects to upgrade RSH for a variety of new and existing browsers: IE7, Opera, Safari/Mac and Safari/Windows. I asked Brad to let me take care of his baby for several reasons. For one thing, I've been an enthusiastic user of the library. For another, I've been wanting to get involved on a more formal basis with open-source JavaScript projects. But most of all, I believe RSH remains a great tool for folks who want a solution to the Ajax history issue without the overhead of a larger Ajax framework.

I'm currently working with Brad to migrate RSH to Google Code, get acquainted with the bug base, and start tackling the thorny issues surrounding Ajax history support in the 2007 browser landscape. I look forward to shamelessly pilfering the many fine solutions uncovered by a large community of developers since Brad's initial work. (Brad was kind enough to point me to this blog post from Bertrand Le Roy, which lays out many of the aforementioned fine solutions and thorny issues.)

In the meantime, I'd love to hear from RSH users about their hopes for the future of the framework. Comments, please, or ping me directly at bdillard (at) pathf.com. Thanks!

• Digg
• Reddit
• del.icio.us

Comments (12)

agile ajax

IE6: The zombie browser

Brian Dillard, Wednesday, September 5, 2007 @ 5:45 am

Paul Graham's much-dissected essay Microsoft is Dead offers some witty and perceptive analysis, but it sidesteps the fact that Microsoft's rotten corpse will take decades to decompose. In the meantime, we still live in a world where most people trawl the Internet with a Microsoft browser. I've already linked to Kevin Hale's perceptive essay On the Tenacity of Internet Explorer 6, and I've already covered Eric Meyer's useful techniques for taking advantage of IE7's power while continuing to support IE6. But I've got a few more links to add to Dietrich's and my back-and-forth about the state of JavaScript tooling. I regularly stop by the IEBlog the same way I keep tabs on the neighbors I don't really like but have to live near. They recently added a more in-depth post about Ajax View, a pretty cool profiler that they'd previously covered along with other IE development tools earlier this summer. In a previous post, I surmised that most front-end developers code for Firefox first, then put off their Safari/Explorer testing till the end. Maybe if IE tooling continues to mature, we'll see less of that.

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

.Mac improvements: That’s it?

Brian Dillard, Friday, August 17, 2007 @ 5:30 am

Amidst all the hardware news at Apple's Mac-focused media event last week, it was easy to overlook the announcement of some tweaks to the widely reviled .Mac web-services suite. Easy to overlook not because the announcement got no play, but because the improvements were so underwhelming. Even with 10 times the online storage space (10 gigs, up from 1 gig) and a slick new Ajax-backed photo service, the upgraded .Mac suite still costs $100 a year. Meanwhile, most of its individual features continue to lag behind the functionality and performance of free services from a host of other providers.

Commentators here, there and everywhere have predicted - and in many cases advocated - the death of .Mac for a long time now. I wonder if Mac newbies' continuing propensity to pony up for the service has something to do with Google's inability to parse the period in ".Mac" and return some relevant search results for such phrases as ".Mac user reviews." [Here's a hint: search for "dot-mac sucks" instead.] There's no shortage of users who find the service disappointing, and the latest tweaks aren't likely to change that.

Based on the demo I've seen of the new .Mac Web Gallery, I can see why an iPhoto junkie might be persuaded to dump Flickr and give it a whirl. But why settle for syncing Safari bookmarks when you can use a social bookmarking service or a bookmark-syncing plug-in for your browser of choice? Why settle for viewing your Address Book entries from a primitive web interface when a service like Plaxo lets you edit them online, too? Why merely view iCal entries online when you can actually edit your Google or Yahoo calendar from any browser? Why use .Mac's painfully slow, frequently buggy online backup service when you can switch to Amazon's S3? Why use the old-school .Mac webmail client when all the major free webmail vendors offer snappy Ajax interfaces? Why host your personal site with iWeb when so many other free or low-cost solutions offer more flexibility and power?

No webapp is perfect, and no single provider offers the breadth of .Mac in a single suite. But cheap or free a la carte services from best-of-breed providers work better for all but the most dedicated (or lazy) Mac users.

Leander Kahney over at Wired stayed up late the night before Apple's presentation to say a prayer that Jobs & Co. would radically overhaul the service. But the best that can be said about the "new" .Mac is that its developers finally seem to be dimly aware that there's this whole Web 2.0 thing happening out there. The future promises some upcoming, though as-yet-undefined, .Mac webmail improvements that could help modernize the service. But the suite's most compelling features are the ones that link one Mac to another, such as Leopard's forthcoming Back to My Mac application. True Apple fanboys may get a lot from such utilities, but they're useless for people in the real world - the ones who log onto Windows boxes at work every day and still want access to the data from their personal MacBook Pros.

My real problem with .Mac isn't that its webapps are sub-par. It's that Apple's overall strategy in the PC marketplace is still so focused on a single, unified desktop experience geared toward the mythical "average user." (Thanks, Walt Mossberg, for making that the most overused phrase in technology writing.) It's such a Microsoftian strategy: continually cramming all the the things a typical customer might need into a suite of pretty-good apps and services whose only real advantage is their supposed integration.

Given that Safari is being positioned as the platform for iPhone software development, it seems likely that core pieces of the OS X desktop experience will eventually get better browser-based simulations. But as a Mac user, I want the data on my machine to play well with third-party webapps, too, in my user-agent of choice. The whole advantage of the web desktop model is that all of my data lives in the cloud and, thanks to public APIs, I can interact with it through a broad range of providers. I can use the out-of-the-box UI or create my own. I can aggregate Remember the Milk into my gCal with a widget instead of waiting for Google to come up with a first-rate to-do list manager. I'm not locked into a single piece of hardware, operating system or software vendor. But locking me into a monolithic suite seems to be the whole point of Apple's desktop strategy, .Mac included.

Right now, all .Mac does is sync data between Macs and allow me to access a subset of that data, in read-only mode, through the browser. That's simply not good enough, and it hasn't been for a couple of years now. Apple should be integrating each of its elegant, easy-to-use but fairly vanilla desktop apps into a web-services architecture. That way, I can use my Mac as an oasis of no-fuss desktop computing at home, but still have the power and the flexibility to do what I need to do from any other machine or physical location.

I get why Apple's user interfaces are geared toward somebody with my grandmother's level of technical proficiency. But why not set up .Mac so that third parties can create more powerful and varied UIs on top of the underlying services? That might actually be worth $100 a year. In the meantime, .Mac and the Macintosh platform are positioned as one-size-fits-all, all-or-nothing propositions. And there's nothing new about that, media event or no.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax