Latitude.

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!

My dream browser.

I got inspired by the iTunes sidebar today to mock up a browser interface that I had thought about for the last few weeks. In iTunes, a ‘hub application’ approach is taken to music and video content, simplifying and streamlining the experience from acquiring content, to organising and viewing it. I am aware of several ‘new generation’ browser projects, but none really line up with my ideas.

Let me show you what I came up with.

Continue reading My dream browser….

Leopard; Less work for developers.

I must once again graciously bow and thank Apple for taking mundane work out of my hands. Via Matt Legend;

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.

Delicious Library 2 preview.

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?).

Truths on Resolution Independence.

Looking back, the Iconfactory’s post on resolution-independence has some holes in it (and looking back now, this post has too - see the end of the post and the comments).

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.