It’s been a while since I released the first mockups and some explanation behind my ‘Dream Browser’. Several developers have contacted me with the desire to develop it, and some have already actively begun programming whole aspects of it. I’m very pleased with the activity, and to help the efforts, I have decided to create a design document and a centralised website to manage the project development. There’s also a working name; Latitude.

For now, I have created some mockups of the full-screen browsing mode, with an automatically hiding toolbar and an image with a roughly mocked up set of tabs for the full-screen mode. Additionally, I’ve made a mockup for the history feature, activated with the ‘Time Machine’-like, which also shows the ‘expanded’ mode, which is quite similar to how Safari looks.

To get some critique and mostly misunderstanding out of the way; one of my primary goals in this browser interface is to minimalise the amount interface clutter, although it may not seem that way. I don’t want to eliminate tabs or add some sort of permanent sidebar; a browser should still be usable as we use it today. However, having multiple sidebars, menu’s, or even full overlapping views that are opened with widgets that are in wildly varying positions in the interface. This browser, as I outlined in the previous post, uses a sidebar to consolidate various features that are now scattered throughout a browser, and helps to reduce clutter by also adding elements like the conventional ‘tabs’ to the sidebar. The ‘expanded’ viewing mode, as shown in the ‘history’ interface mockup without a sidebar active, will be your preferred state for viewing content.

I’ll update this new category when the document finishes or to keep tabs on community activity. Thanks for all the input and hard work so far!

Let me show you what I came up with.

For the average internet’s user, using a browser isn’t merely parsing HTML anymore; we stay on top of news and social ‘updates’ like blogs, RSS feeds, and services like Twitter. We create and share imagery or photos. A massive market has arose in serving and viewing video content. In short; these days, using a browser doesn’t necessarily mean the user is going to want to view a website anymore.

In iTunes, the key to unifying a universe of very different content is a set of groups in the sidebar. This approach allows a very intuitive way of interacting with the main view; there’s just a single window to worry about, and when in doubt, the sidebar explains anything you might want to know. Where do I drag this object? Where could that file have gone? Where am I in the application’s structure?

A screenshot of my dream browser. Click for larger on flickr.

In my interface mockup, I got rid of the notion of tabs, and present websites in the ‘website’ group, the most important sidebar item. The items in the sidebar are relatively limited; your open pages, a control to open a new page, and your favorites, which invokes a list of your favorites in the main view. Again, there’s no way to get confused how you got to your favorites list and how you switch back to a website; it’s all in the place you know you have to look.

As you can notice, the sidebar contains groups for managing and using ‘features’ of everyday websites; news, photos, and videos. If this application were ever to become a reality, I’d suggest the sidebar to be extendible openly; imagine the same, unified interface to all your possible needs. An addition could be made to allow the easy tracking and viewing of classifieds and auction bids, or for working with online maps. The possibilities are virtually endless.

I suggest that in a browser, news is something that should be something that can be achieved independently of sources. The sidebar of my mockup contains the Frontpage feature, a Newsmap-style diverse ‘paper’, composed of high ranking recent news items laid out automatically in a newspaper-like arrangement. The content aggregation is quite similar to Google’s News service. The ‘Recent news’ feature shows the most recent news from credible sources, updated in real time. Lastly, there’s our classic RSS subscriptions, which I don’t think requires any further explanation.

Weren’t you ever bothered by a (perhaps intentionally) crippled Quicktime player? In the days where OS X comes with Quick Look, capable of full screen video playback (even over the network), the experience of video on the internet is very poor. I suggest being more clever about viewing video content; let the user detach video content from websites and view it fullscreen. When a website opens a pop-up with just a Quicktime movie in it and the pop-up is about as large as the video, wouldn’t it be much nicer to open up such a light-weight video window instead of a clumsy browser window instance with a crippled player? Together with integration of movie content in the sidebar, such as movies from your contacts (which could tie in to Youtube subscriptions), movie favorites, and your own personal 24/7 channel with suggested videos. This doesn’t even have to be a very accurate service; it’s only to provide the user content at his discretion.

Watching video online might actually become fun again.

The same basic idea goes for photos. Using address book information and .Mac gallery / Flickr services, you can make a stream of images from your contacts. Image favorites deserve their own category, of course, for visual browsing, and again, providing ‘unexpected’ content through a stream like recently uploaded photos to online services allows for true ‘browsing’ of the content.

I’ve heard some critique on this idea. The first and foremost was the prioritizing of the interface on the same level as the internet content. I believe it would be a great idea to have an ‘extended’ mode that essentially minimizes your sidebar and window profile to maximise your viewing size. This could also help your view websites, news, videos and image slideshows.

This ‘viewing’ state of the window is also what I intend to use for my second point of critique, the viewing of history. I haven’t heard any questions in regards to history when I presented my mockup to people, but personally, I think browsing history should be a lot more visual. In the toolbar, you can see a ‘Time Machine’-like button, that allows you to, yes, go back in time and browse your visiting history quickly and visually. Alternatively, you can search through it or bookmark pages directly.

As a last addendum, I always loved the way iTunes handled downloads. I always manage to get my downloads window stuck behind my browser window, forcing me to expose it to the foregrond or digging it up through a menu. With iTunes, or my dream browser, you know where to look.

Lastly, I certainly won’t code this application or pay someone to make it. It served as personal experimentation and I shared it as inspiration after being massively disappointed with the Mac beta version of Firefox 3.0. I hope you enjoyed reading and seeing what I dream to see in a browser one day.

We’ve all stolen Apple’s icons for things; now we’re officially allowed to. There are lots of new standard images available via NSImage -imageNamed:, including the Safari bookmarks image, all kinds of arrows, the gear icon, the Computer icon, Bluetooth and Bonjour logos, user account icons, the Info icon, and many more. The size of your app could drop significantly, as could your icon-design expenditure.

As could my monthly income! But no, I’ve got more than enough interesting work on my hands. Matt has a fantastic (and that’s a horrible understatement) write-up of some highlights in the Leopard feature lineup of developer tools and API’s. Read his long and bookmark-worthy post here.

Scott Stevenson has put up a short but very impressive teaser of Delicious Library 2. After the web interface preview of not too long back, this is very nice to see. One of the apps I am looking forward to the most when Leopard comes out (and the iPhone SDK, of course, can you imagine scanning in barcodes wirelessly with your iPhone?).

Why, you ask? They claimed that PDF’s in the user interface as a new format instead of the current TIFF files, the entire OS would come to a screeching halt, that icons would go beyond megabyte sizes and general mayhem would throw all resolution-independence craving Mac users into a purgatory. We knew different then, we know different now. A few months back, I posted about the ‘new’ Oxygen icon suite for KDE, being all SVG-vector based, and it didn’t wipe Linux off the face of the Earth. Instead, some optimized SVG files and rendering tricks made it work quite good, and these days, some ‘dock’-applications for GNU/Linux put the SVG’s to good use.

You can test this kind of stuff on OS X too, you know. First of all, as we all know from the rather public Resolution Independence segment of the “Leopard Features in Cocoa” session, free on the ADC Online iTunes page that we can define image resources of varying DPI values. You’d have the same size images if you open them in, say, Preview, but once zoomed in, it’s obvious that one contains four times as much pixel data. Assume that drawing units (points) are independent of screen pixels - if you take a 100*100 point image with 72 DPI, it’s 100*100 pixels. if you take a 100×100 image with 288 dpi, you get 400*400 pixels, but this 288 DPI image isn’t ‘larger’ on-screen; it would be as large as the 72 DPI image on a 288 DPI screen.

But you can be more flexible with vector resources. Now, I wouldn’t really use my own icons in vector format, because it -would- put the OS to a screeching halt, but we all know that there is no plan to make the Dock icons vector - instead, we are simply putting 512 pixel icon resources in all new ICNS files to keep the scaling possible. Toolbar icons, on the other hand, are often very simplified graphics. Take the GNOME Tango icon set’s trash icon as an example;

As you can see on the right, this SVG icon has a 72 dpi version in which the dark outline is exactly one pixel wide - we could compare this to toolbar icons, which generally have the same characteristics. One pixel-outlines, and often a lot of pixel-art to get it all looking proper in the 32*32 pixel space. No more! In OS X 10.5, we can do it the Tango way. It takes two to Tango, doesn’t it? In our case, one PDF vector resource (we don’t generally use SVG’s, OS X has a PDF graphics subsystem with Quartz) and either include a DPI-ready vector resource in the PDF (one that has a 1 pixel border on 72 DPI, for instance), or a separate file (a multi-representation TIFF) that is used with a little bit of Cocoa’s help. Apple has been kind enough to give you something to grab the screen’s DPI value and thus, do something with that. In the session, a solution like this was suggested;

NSImage (pointer) Name=Imagename Size={100,100} Reps=(
&nbsp NSBitmapImageRep (pointer) Size={100,100} Pixels=100×100
&nbsp NSBitmapImageRep (pointer) Size={100,100} Pixels=400×400
)


Of course, assumed here is that we are talking about our earlier resources; one 72-dpi 100*100 pixel image, and a 288 dpi 400*400 pixel image get put in place conditionally. Cocoa will chose the resource accordingly. If we can, however, we should use vector resources. They won’t ever give problems because they scale with our interface - you can set the PDF as the icon resource and as the workspace scale factor gets higher, the graphic scales accordingly and loss-less. I hear you say that perhaps, some high-end systems with high scale factors are able to render vector graphics of increased complexity without too much strain, and all systems with a smaller scale factor (I assume laptops and low-end desktop systems) don’t really want to render out vector graphics because they are both hard to parallelize and take battery life in the case of portables. Although there is an argument that rendering out vector resources smaller is faster anyway, representing vector graphics still is a lot more intensive than just displaying bitmap data. Perhaps an if switch is needed?

- (CGFloat)userSpaceScaleFactor;

This method returns the workspace’s scale factor and lets you act on it accordingly. It’s simple to set up this method and make a switch of resources (I will leave that as an exercise to anyone who has a ‘Leopard to build on’). Afraid this might make your application bigger? I wouldn’t worry about this too much. If you would upgrade your toolbar to this dual-resource system, all your 32*32 resources wouldn’t need the 128*128 resources, whereas the vector resources included are generally smaller than any bitmap data. It’s a small price to pay for a better looking app. Now go forth, and make sure I see some both efficient, pretty, and resolution-independence ready apps soon! If you need help, you can get information about my services at icondesigner.net.

Edit: Craig Hockeberry of the Iconfactory has commented on the whole matter, and after a bit of chatting I agree that it is overboard for an interface designer to talk about these matters of switching resources - however, it was meant in a ways of throwing around idea’s. I must say that I was wrong in a few other points; vector in PDF cannot yet be seen as a medium for all toolbar icons because it’s not efficient enough. I’d like to thank Craig for all the input.