Imx Fix in my experience
 
Recently in Web Browsers Category


December 4, 2009 2:19 PM


socialite_single.png

As noted by John Gruber at Daring Fireball, the simplicity of a Twitter post opens up a lot of UI opportunities. As a result of that and available APIs, we are seeing more and more Twitter clients (I have four on my iPhone), but beyond that, we are seeing the start of the next logical step, convergence.

Socialite and Raindrop are the two best examples that I know. These are applications that aggregate your social footprint on the internet and attempt to wrap some meaningful UI around it all. Raindrop is still in early dev and requires you to be a bit savvy if you want to use it, but Socialite is (Mac only and) immediately available and is quick to set up, so give it a try.

Something worth looking at when using a variety of Twitter apps and these convergence apps, is how the designer has chosen to organize and present everything. If you boil things down a bit, a tweet, blog entry, Facebook update, Flickr post, rss feed and email, all have the same basic parts...

  • The person who sent it (which includes a way to reply, such as an email address or @twitter account)
  • The content.
  • A title/subject/name.
  • Some other bits of data, such as time/date, category names or tags, etc

With such a simple set of elements, there is a ton of opportunity to design a look and feel around them. The Raindrop folks have been sharing their design ideas on Flickr and you can see they have been exploring many ideas. It's not a surprise to see a 3 pane UI like you have in Outlook, Mail.app and NetNewsWire.

Socialite has completely Mac-ified that experience, and while some folks think the UI is just too intense, I think it's done elegantly and sensibly. You can see though that there is a lot you can do in the app, especially on the right side of each entry. At times there are 5 icons and one of them has a menu with 15 actions you can take. But overall, the UI is based on a use case you already understand, email.

Back to Twitter clients, compare something like Tweetdeck (which is entirely consistent from iPhone to its Air counterpart) to something like Tweetie 2. The base philosophy of these two clients are very different, but they use the same source material. As Raindrop continues to develop, it will be interesting to see if they can find a different but equally (or more!) usable format than you find in Socialite.

For a good overview on Socialite, check out Mashable's article from last week.



March 24, 2004 9:58 AM


A voice enabled browser? Bah, I was doing that years ago.

August 12, 2003 9:06 AM


For a very long time, I have felt that OmniWeb is an irrelevant annoyance on the web browser landscape. I mean, who are they kidding? another browser to support, that no one uses? I'm having a hard enough time writing compliant code that renders consistently in Mozilla and Internet Explorer. Safari came along and completely marginalized a mostly marginalized browser.

That has changed. OmniWeb 4.5 now "uses the WebCore framework from Apple for greatly improved standards support." That's the engine that runs Safari, so OmniWeb is essentially, just another Safari browser, but with one crucial difference. There's a JavaScript Console now, that shows me errors that might be occurring in the page I am developing. The error messages are a bit cryptic, but are still more useful than the errors that Safari gives you (read: none). I would prefer that the error messages were a bit more like Mozilla's though.

In the environment that I work in, we have more than 15% of our users running Safari. That's a pretty high percentage, and definitely passes the "they can't be ignored" ratio (which is, imho, about 8%). Not only can't they be ignored, but functionality can't just gracefully degrade, it has to be on par with IE and Mozilla support. OmniWeb's JavaScript Console makes that easier. If I were the business/marketing wonk down at The Omni Group, I'd be pushing that behind the registration fee. But I'm not, so I'm glad it's not.

July 24, 2003 9:33 AM


It's been a busy week so far (between baby, work and other events) so the postings have been meagre; sorry about that. I had to post something about this thing though...

Microsoft may have unwittingly started a revolt against its Internet Explorer (IE) browser by discontinuing it as a standalone product and blurring the future of the current version, IE 6.
And here's on example of the fallout...
Say explained that First Direct is due to update the security certificate on its secure servers and unless users had upgraded to the latest version of IE, they would receive "odd messages" questioning the authenticity of their connection. Four weeks after asking Microsoft for advice on the subject, he is still waiting for a response.

"This is a tricky one for us because we have no control or influence that we can exert,"
Notice the lack of control there. If there's one thing a business can't stand it's uncertainty, and a lack of control breeds that feeling rabbits on Carrot Island. Losing control over your application, and the method of making money, to another corporation that is known to be horribly predatory, can only be bad. How do you go about mitigating that risk? Adopt standards, support Mozilla and Safari, and avoid MSFT specific code.

July 16, 2003 9:13 AM


Recently I speculated about the demise of Netscape, and more to the point, that Netscape would not meet an untimely end. Apparently, I was wrong, and it's pretty depressing to see it happen.

The point I made about the MSFT/AOL deal was that AOL would still prefer to NOT place control of its business into the hands of its competitors. That's definitely true, but I carried that into a hope that Netscape wouldn't be scuttled. At least Mozilla will carry on with active funding from the likes of AOL, IBM and Sun.

July 2, 2003 9:42 AM


moz_14_icon.gifI have been working on a reformation of Kalsey's CSS tabs code to NOT use unordered lists and list items in favor of divs and spans. I'm also adding some JavaScript to change the className on mouseover to change the menus without having to click and get a new page (something I am sure Mr. Kalsey has thought of before).

One striking fact that has come out of the work, is that Mozilla 1.4 on Mac OSX is extremely fast (download). It renders the code I have way faster and cleaner than Safari. Perhaps I haven't been paying attention recently, or maybe I'm in a Safari induced haze, but this new release is just awesome and might become my default browser. Oh yeah, and it has a nice new icon.

Anyone else have any thoughts?

April 9, 2003 9:39 AM


Is it me, or can you not export your bookmarks from Safari? It's possible to back up your bookmarks file by going to this file path...

/Users/your_user_name/Library/Safari/Bookmarks.plist
...but I'd like to have a mechanism in the broswer to export this to (X)HTML or RDF or even RSS.

Apple's PLIST format is XML, and parseable, and transformable. So ultimately, what I really want is for someone (even Apple) to write something that can transform my Safari bookmarks into the format Mac IE5 reads and into the format that Camino reads (and vide versa).

Some sort of cronable job would be optimal where all of my bookmarks would be sync'd between my browsers, which would require transformations from and to each format. This avoids exporting, and then importing, which is time consuming. I can't even imagine writing the diff code.

Not even the Camino authors have Safari bookmark imports working yet, so maybe I'm asking for a bit much...

Note that, although it initially shows you Internet Explorer's bookmarks, you can import bookmarks from OmniWeb, iCab, Mozilla, Netscape, and Camino itself. Safari bookmarks cannot yet be imported.
One can wish, can't he?

March 20, 2003 8:01 AM


While discussing some 'quirks mode' and 'strict mode' browser behaviors, and regarding the need for more correctly written HTML, Dave Hyatt asks...
If you don't behave strictly when in standards mode, how will people ever write valid HTML?
Sorry dude, that's a false question. "Writing Valid HTML" is like "burning clean coal." It can sort of be done, but there's always something making it dirty, or systems that are so draconian that they sap out the value of the resource (be it coal energy, or perfectly valid XHTML).

Human nature, poor markup rendering engines that are widely spread, and idiotic decisions like making XHTML 2.0 not be backwards compatible, will make "strict" the sigma seven on the curve of diminishing returns.

Should we try to write valid markup, and assume it will be rendered with tender loving care? Of course! And I think Dave's efforts, to make that a reality by following reason and altruistic goals, are good efforts. Unfortunately, browsers can't trust the markup they will have to render, and web developers can't trust browsers not to be quirky (or completely stupid).

Should strict mode be "less quirky" mode or should strict mode be "if it isn't perfect, it's going to be an f'ing mess" mode?

February 21, 2003 9:01 AM


Regarding the original web browser Andreesen says...

Things like the Back and forward button, we never intended that to be a permanent part of the interface. But people get locked into metaphors. You have to be careful with the metaphors you put in front of people because once they click onto one, that's it.
This is pretty much true of web apps, brochure-ware and compiled applications. And this represents the largest risk to the high fidelity prototype. You want to under promise and over deliver on your projects, but you need to draw a fine line between giving away the store and not delivering the goods.

To mitigate this, you have to know what you are talking about, and how to execute on various requirements as they arrive on your doorstep. Pattern languages can help but real experience will better inform your decisions. Andreesen's comments are based on experience, but this next one is off the mark...

I think it's so funny that Apple comes out with a new browser in 2003. Where were you guys six years ago? I wish them the best, but it's not as if you're about to see Safari go from 0 percent market share to 47 percent.
In its (puny) market, Safari owned that market overnight, so in terms of that bit of business strategy, Marc missed the point. Safari is a good move for Apple due to the fact that none of the seven browsers I have installed on my tiBook are fully adequate. But I digress; Andreesen's UI instincts seem to be finely tuned, even if he's supposed to be a business guy.

February 20, 2003 9:33 AM


One of the great things about Internet Explorer 5 for the Mac (IE5) is that it's pretty tight on the html and css standards, and kind of behaves like it's PC cousin. That made developing sites somewhat easier because you could reasonably guess that JavaScript you wrote would work in both, and IE5 has been dominant on the Mac platform since is was made the standard (which was a few years ago). Enter Safari.

Now, we have the KHTML engine to deal with since that is what Safari is based on, and if you cover Mac news, or software, or Mac-whatever, you need to support it, because on the Mac IE5 use has evaporated overnight. Those same results appear at this site, but I see a larger contingent of PC based browsers than Daring Fireball does.

« User Experience | Main Index | Archives | Weblogs and Blogging »