I plan to develop a mac OSX app that has a UI similar to that of iPhoto - a panel on the left and a grid view of images on the right. I am thinking of using NSSplitView to create two panels and using NSCollectionView for the grid.
I guess this must be a pretty popular and common UI pattern for mac apps. I am new to cocoa development. Can anyone with previous experience point me to any related cocoa code samples and design document?
Thanks a lot in advance.
N.B.
This missing piece here is an NSOutlineView in source list mode, put that in your left pane. But otherwise seems like a good place to start.
You might also be interested to see what the developer of Sonora approached this problem; although this is a music app the layout is almost the same.
I’m risking this question getting closed as “not constructive / argumentative”, as there is no single definitive answer that I’m looking for… but I hope we can make this work. Bear with me.
So. Let’s talk about Mac apps. Cocoa and AppKit are the workhorses on Mac desktop, that can be used to construct classic-looking Mac UI-s. Here’s an example.
The iTunes preferences dialog is a classic-looking Mac UI. Standard toolbar, checkboxes, sliders, separators, buttons. Mac engineers know how to make these, and it’s easy and fun these days with AutoLayout & co.
More recently, though, another style of Mac apps is emerging, that I’d call “modern” apps. In particular, I’m interested in document-based apps, where the document is single-window, decorated with crisp-looking sidebars and other components. Here are two examples (Sketch and Pages).
I’m interested in ideas about how these UI-s are constructed, and what kind of components are used. Is AppKit sufficient to achieve this? I read somewhere, but can’t recall the reference, that iWork these days largely forgoes AppKit and the UI just consists of a bunch of hand-drawn CALayers. I’m not so much interested in the document canvas (a whole another subject) as I am in the sidebar, toolbar and their contents.
OK, let’s try to salvage this question with some specific subquestions…
General window composition for both apps—is it NSToolbar on top, and NSSplitView in the body area, or something more?
Sketch tree view on the left—can I achieve this with NSOutlineView, or is there something more going on?
Pages sidebar—what kind of AppKit components are used here, vs custom drawing? (One curious fact that tells me that custom drawing is going on—when I expand/collapse the “Spacing” or “Bullets & Lists” sections, there is no animation.)
Don't be fooled by current design choices. IMHO we're building apps the same way we always did it, albeit single window interfaces became more popular in recent years.
But that's just a matter of whether you stuff your NSView subclasses in subviews or dedicated windows.
The views themselves shouldn't care at all - in a good application design.
The apps you've mentioned use a mixture of custom and standard controls.
Like apps always did - back to the days of NextStep (or System 7).
I've learnt Cocoa + Objective C primarily for iPhone development, and I need to utilize this skill set to build a very basic kiosk application for OS X in a couple of days. The application is basically as follows :
The setup has two touch screen monitors, the app must be running full screen mode. The monitor on the right acts as a detail view to a list of options on the left. There are 3 options on the monitor on the left. Picking one will play a movie on the right, Picking two will take you to a quiz, Picking 3 will pull up a Webview.
The user may not use any other operations on the PC. (I've started reading about OS X application development and realized Cocoa provides a kiosk mode for these types of apps)
My questions briefly are
Firstly, any help on how to get my app running in a kiosk mode is much appreciated! I'm under a bit of a time crunch (2 days to get all this done, talk about life in startups!), so completely static content is fine, I'm slightly worried about how OS X will handle full screen mode if an app has been written in a smaller window size. (Scaling etc.)
Next, assuming there are two windows, one on each screen, how do I deal with focus? If the user suddenly gets bored with content on the right and touches the window on the left, the first touch will probably act to focus the window and the second will act as a click on the button. I'd like to avoid this scenario!)
What are the navigation paradigms in OS X ? I'm guessing it's not as simple as [navigationController pushViewController]? In short, how do I display a new view over an existing view?
Thanks,
Teja
Firstly, any help on how to get my app running in a kiosk mode is much appreciated!
http://developer.apple.com/library/mac/#technotes/KioskMode/
Next, assuming there are two windows, one on each screen, how do I deal with focus? If the user suddenly gets bored with content on the right and touches the window on the left, the first touch will probably act to focus the window and the second will act as a click on the button. I'd like to avoid this scenario!)
Click-through is the default. If you have any custom views, respond to acceptsFirstMouse: with YES to support click-through in them.
What are the navigation paradigms in OS X ?
Typically either window-based or source-list-based. Your application is atypical.
I'm guessing it's not as simple as [navigationController pushViewController]?
It's simpler and more complex at the same time. There is no stack to manage; you can have multiple windows up at the same time. It gets more complex when you want everything in one window (as in your kiosk-mode app), in which case you end up using tab views (with or without tabs) to enable the user to switch from one view to another.
In short, how do I display a new view over an existing view?
You don't. Layering one view over another in the same superview is barely supported at all in AppKit, and almost always wrong.
In a normal application, you should make multiple windows. In an app like yours, you'll need to use tab views. View controllers may help you here, although NSViewControllers are very different from UIViewControllers (as I mentioned, no view stack); they're more similar to NSWindowControllers.
I'm from a Windows programming background when writing tools, but have been programming using Carbon and Cocoa for the past year. I have introduced myself to Mac by, I admit it, hiding from UI programming. I've been basically wapping my OpenGL code in a view, then staying in my comfort zone using my platform agnostic OpenGL C++ code as usual.
However, now I want to start porting one of my more sophisticated applications to Mac OS.
Typically I use the standard Visual Studio dockable MDI approach, which is excellent, but very Windows-like. From using a Mac primarily now for a while, I don't tend to see this sort of method used for Mac UIs. Even Xcode doesn't support the idea of drag and drop/dockable views, unfortunately. I see docked views with splitter panels, but that's about it.
The closest thing I've seen to the Visual Studio approach is Photoshop CS4, which is pretty nice.
So what is the general consensus on this? Is there are more Mac-like way of achieving the same thing that I haven't seen? If not, I'm happy to write a window manager in Cocoa myself, so that I can finally delve in an learn what looks like an excellent API.
Note, I don't want to use QT or any other cross-platform libraries. The whole point is that I want to make a Mac app look like a Mac app, leave the Windows app looking like a Windows app. I always find the cross-platform libraries tend to lose this effect, and when I see a native Mac UI, with fancy Cocoa transitions and animations, I always smile. It's also a good excuse for me to learn Cocoa.
That being said, if there is an Open Source Cocoa library to do this, I'd love to know about it! I'd love to see how someone else achieves this, and would help smooth the Cocoa learning curve.
Cheers,
Shane
UPDATE: I forgot to mention a critical point. I support plugins, which can have their own UI to display various plugin specific information. I don't know which plugins will be loaded and I don't know where their UI will live, if I don't support docking. I'd love to hear people's thoughts on this, specifically: How do I support a plugin view architecture, if the UI can't change? Where do I put the plugin views?
Coming from a Windows background, you feel the need to have docking windows, but is it really essential to the app? Apple's philosophy (in my opinion) is that the designer knows better than the user how things should look and work. For example, iTunes is a pretty sophisticated app, but it doesn't let you change the UI around, change the skin, etc., because Apple wants to keep it consistent. They offer the full view, the mini player, and a handful of different viewing options, but they don't let you pull the source list off into a separate window, or dock it in other positions. They think it should be on the left, so there it stays...
You said you "want to make a Mac app look like a Mac app", and as you pointed out, Mac apps don't tend to have docking windows. Therefore, implementing your own docking windows is probably a step in the wrong direction ;)
+1 to Ken's answer.
From a user perspective unless its integral to the app like it is in Adobe CS or Eclipse i want everything as concise as possible and all the different options and displays out of my way so i can focus on the document.
I think you will find with mac users that those who have the "user skill" to make use of rearranging panels will in most cases opt for hot key bindings instead, and those who dont have that level of "skill" youre just going to confuse.
I would recommend keeping it as simple as possible.
One thing that's common among many Mac apps is the ability to hide all the chrome and focus on your content. That's the point behind the "tic tac" toolbar control in the top right corner of many windows. A serious weakness of many docking UIs is that they expect you to have the window take up most of the screen, because the docked panels can obscure content. Even if docked panels are collapsable, the space left by them is often just wasted and filled with white space. So, if you build a docking panel into your interface, you should expect it to be visible most of the time. For example, iTunes' source list is clearly designed to be visible all the time, but you can double-click a playlist to open it in a new window.
To get used to the range of Mac controls, I'd suggest you try doing some serious work with some apps that don't have a cross-platform UI; for example, the iWork apps, Interface Builder or Preview. Take note of where controls appear and why—in toolbars, in bottom bars, in inspectors, in source lists/sidebars, in panels such as IB's Library or the Font and Color panels, in contextual HUDs. Don't forget the menu bar either. Get an idea of the feel of controls—their responsiveness, modality, sizing, grouping and consistency. Try to develop some taste—not everything is perfect; just try iCal if you want to have something to make fun of.
Note that there's no "one size fits all" for controls, which can be an issue with docking UIs. It's important to think about workflow: how commonly used the control would be, whether you can replace it with direct manipulation, whether a visible indication of its state is necessary, whether it's operable from the keyboard and mouse where appropriate, and so forth. Figure out how the control's placement and behavior lets the user work more efficiently.
As a simple example of example of a good versus bad control placement and behavior in otherwise-decent applications, compare image masking in OmniGraffle and Keynote. In OmniGraffle, this uses the Image inspector where you have to first click on an unlabeled button ("Natural size") in order to enable the appropriate controls, then adjust size and position away in a low-fidelity fashion with an image thumbnail or by typing percentages into fields. Trying to resize the frame directly behaves in a bizarre and counterintuitive fashion.
In Keynote, masking starts with a sensibly named menu item or toolbar item, uses a HUD which pops up the instant you click on a masked image and allows for direct manipulation including a sensible display of the extent of the image you're masking. While you're dragging a masked image around, it even follows the guides. Advanced users can ignore the HUD entirely, just double-clicking the image to toggle mask editing and using the handles for sizing. It should be easy to see, with a few caveats (e.g. the state of "Edit Mask" mode should be visible in the HUD rather than just from the image; the outer border of the image you're masking should be more effectively used) Keynote is substantially better at this, in part because it doesn't use an inspector.
That said, if you do have a huge number of options and the standard tabbed inspector layout doesn't work for you, check out the Omni Group's OmniInspector framework. Try to use it for good, and hopefully you'll figure out how to obsess over UI as much as you do over graphics now :-)
(running in slow motion, reaching out in panic) Nnnnnoooooooo!!!!!
:-) Seriously, as I mentioned in reply to Ken's excellent answer, trying to force a "Windowsism" on an OS X UI is definitely a bad idea. In my opinion, the biggest problem with Windows UI is third-party developers inventing new and inconsistent ways of presenting UI, rather than being consistent and following established conventions. To a Mac user, that's the sign of a terrible application. It's that way for a reason.
I encourage you to rethink your UI app's implementation from the ground up with the Mac OS in mind. If you've done your job well, the architecture and model (sans platform-specific implementation) should clearly translate to any platform.
In terms of UI, you've been using a Mac for a year, so you should have a pretty good idea of "the norm". If you have doubts, it's best to post a question specifically detailing what you need to present and your thoughts on how you might do it (or asking how if you have no idea).
Just don't whack your app with the ugly stick by forcing it to behave as if it were running in Windows when it's clearly not. That's the kiss of death for an app to Mac users.
I have a question about the windows mobile development.
I created a mobile form on the windows mobile 6.0 test project. But that example form slightly larger than the vertically normal pocketpc forms. I now everybody said you can press the scrollbar for accessing bottom or any location of the form.
But i need to use the finger for easy navigating form areas. This kind of iphone :)
Is it possible ? how can i make this ?
Windows Mobile 6.5 adds gesture support, that is supposed to allow such functionality for finger control. Of course, your code has to take advantage of it.
You can also write your own, which isn't difficult, but still cumbersome.
My answer could be classified as subjective. I try to now show the scroll bar when possible for just that reason. On most devices that have touch screen, you can scroll using you finger (and I'm a somewhat large guy -- 6'3" with farmer kid hands).
But if you are displaying a grid, that isn't always possible. The results can go off the screen very easily. Oh well, grab a pen and hit the scrollbar.
Other screen elements that can help: tab control. separate your controls into groups and put each group on a separate tab. I also do a lot of wizards with LARGE next and previous buttons.
But in all of this, if it is designed to be stylus free, just pray the user doesn't have to type anything using the screen soft keyboard. That just doesn't work with a finger.