Mac OSX has this feature called (I think) 'Services'. It is available in the menu bar under the filename of the application (e.g. Finder) and then selecting 'Services'. This gives you access to a list of applications that provide 'services'. For example, if you are browsing a website with firefox and you have some text selected on the page, the services list has an entry for Mail > send selection.
I've been using a Mac for almost 3 years and I've literally never used it (but I've known it to be there from the beginning).
So, is it worth for an application developer to provide support for this (i.e. provide some services actions)? Or would it be a waste of effort (because no one, or very few people, uses it) ?
I've attempted to use it a few times over the past ten years.
Previously, the menu was cluttered with disabled items, and uselessly disorganized. Actually making a selection was unpredictable, as the few items that weren't disabled were often supposed to be. The appearance of possibly doing something was itself just a bug.
However, it appears to be much improved in 10.6. If you want to provide a universal, context-sensitive service, I'd say go for it. Maybe it will be the killer app for this decade-dormant delivery doodad.
I have used Mac OS X since Developer Preview 2 (and earlier versions of Mac OS before that, though they didn't have the Services menu), and I have never used the Services menu.
I'm sure some people, somewhere must use them occasionally, though I have never seen it. I would say it's likely a waste of effort unless one of your users specifically requests the feature.
I use them from time to time. But other pretty high profile users seem to think they're the dog's bollocks. So I suspect it depends on your audience.
Only you can judge whether there's the remotest chance your users will care, but I certainly wouldn't rule it out. If your software genuinely does provide a service that would be of benefit beyond its own application context, exposing that as a service definitely seems like something worth considering. You wouldn't neglect copy and paste out of hand, would you?
In 10.6 they are a lot more useful (as Potatoswatter indicates, they are properly Contextual in 10.6, so that it only displays text based services, when you have text selected).
For what it's worth - I've rarely used the Services menu at the top, but have sometimes used them via the context menu - but primarily with Apple's own apps (send to iPhoto, open in Preview). There aren't many third party apps that offer services I find useful.
However, I am aware that some users of journaling/clipboarding software swear by them. WalkyTalky has the right view - if your application exposes a service that is useful (or if you think users would want to regularly select and push data into your app) then adding support would be useful.
(In contrast - if it doesn't, then adding one is just adding to the 'noise' - I have a notebook application that adds a service for every single new notebook created).
Related
I've created a simple Mac app that gives you statistics on your working behavior over time. For example, your average words per minute, what language you are typing in, usage of the delete key, etc. Interesting stuff! However, some test users have said they wouldn't use the app if they didn't know me personally, since it collects keystrokes like a keylogger.
Is there some certification I can get to show that I'm not doing anything nefarious? (I never keep more than one word in memory!) Or will it be enough to have my app signed? Or open-source that part of the code? (Other parts I know I cannot make open source.)
Distributing through the Mac App Store will help, since users can see that Apple has tried your application and found nothing nefarious in it. [Added:] Also, sandboxing your app means that your app is restricted to an explicit set of abilities, which technically-skilled users could inspect. Anything not listed, you're unable to do, so this would be an easy way to prove that you don't send anything back over the internet.
Another thing would be to save all data in user-readable files. No binary plists, no Core Data stores, etc. (Whether the XML variants of either of those should count as user-readable would be more arguable, but for this purpose, I think at least an XML plist would be readable enough. Not sure about Core Data.)
If the user can read all of the raw data you store using applications that they trust (such as TextEdit), and not just your usual fancy in-app presentation of it, then they can check for themselves, and eventually trust, that you're not storing anything they wouldn't want you to.
If any concerned potential users email you about whether you report their keystrokes to your own server via the internet, and assuming that you don't make any internet connections at all (not even an update check), you can recommend that they should install Little Snitch, which pops up a confirmation alert anytime any app tries to connect to something. When they don't see such an alert about your app, they know that you're not phoning home.
You might also, on your product webpage, include a link to a tech profile. Here's Jesper's article proposing them, and here's one example of such a document, for one of his products.
I would think that Gatekeeper would be adequate for most users. If it turns out an app is doing bad things, then Apple could pull the plug on a malware developer. So that and maybe some time live should establish your program as 'safe' to those who are not technically inclined (e.g. cannot understand your source).
Simply distributing it in your or your company's name can do a lot to build trust in an app (provided of course your other products/programs have not violated users' trust).
If you can get the application onto Apple's App Store, then that means they will have checked it for such problems. There's no way they'd knowingly allow a key-logging app on there. Also, signing the app with an Apple certificate ensures that if it has been downloaded from the App Store and later is found to be nefarious, they can black list it.
Open-sourcing code would also be a good idea. I assume you can't Open Source all of it because it doesn't belong to you? If so, then make it clear what technologies it uses and be as open and honest about what the application does and how it goes about doing it.
For some time I've noticed how much the File Open and File save dialogs vary between Windows itself and Applications. In Delphi for example (which I use) you can use the built-in dialogs (which have a folder tree) and direct calls to the Windows API which produce variants of the Windows version, with or without large buttons for 'Desktop', 'My Computer' etc (At least on XP).
As an application developer I'm interested in providing the User with a clean, simple way of loading and saving files. Typically, this requires that I propose a preferred folder where my Application data files are stored but that I allow the User to access other folders - often the desktop and other local drives, and sometimes the network - without difficulty if required.
With the introduction of Vista, we seem to be favouring a 'bits missing' folder navigation tree for Windows dialogs and now, Windows 7 has another 'line-less tree' for navigation. I suspect that if one conforms to Microsofts assumptions and stores everything in ~/documents it's not a big problem. However, if one has to start at the root of a drives tree and there are many directories then it's a right pain - there is no horizontal scrolling so directory names get truncated.
My question is - what do other Application developers use? I wonder whether I should be following this Windows lead or simply sticking to a simple cut-down version of File dialogs over which I full control but risk falling into the past....?
Thanks
Brian
Always use the OS defaults - it'll be what your users are used to, and what they expect. Whatever you do, don't astonish the user. Whatever you do, please don't write your own file-open/file-save dialog.
FWIW, I'm not a great fan of Vista's file-open dialog (why do I have to work so hard to navigate my folders?), but I'd rather that than have to get to grips with something new. The less things your users have to learn, the easier your product is to use.
Since I am currently only coding for customers with Windows XP (in a corporate environment that isn't upgrading just yet) I use the standard dialog boxes.
When we do upgrade, I will most likely continue to use the standard old fashioned dialog boxes, until our customers are ready for a change.
In all honesty, I involve at least a few users in the development process, and I won't start new features unless I can bring one in to sit in front of my development PC to see how it works, and they sign off on it.
For those apps that we write for our web site, we tend to be conservative as well... Focus on clean, understandable design, and introduce fancy new features only when there is a compelling reason, and even then, we tend to involve focus groups.
So all that was a long way of saying "Ask your customers". Give them what they want.
For common elements, such as a logout button on a website, save button in an application, need to be presented to users in an standard, easily discoverable way. How do you go about deciding where in your application to place these elements? Do you research similar apps and try to follow convention? Is there any database that attempts to track the use of these common elements or is this too hard to capture?
The goal is to put UI elements where users expect to find them. You want to leverage the knowledge that they already have about how applications work.
So, looking at the the UI elements for the OS that you are targeting is helpful. Unfortunately, there are some key differences here between Windows and Mac, you will have to pick one or switch based on the OS if you target both.
Looking at applications that are similar to yours is generally not a good idea unless you believe that people using your product are already using these other products and you want them to switch.
Instead, you look at products that are complementary to yours, or products that you expect everyone is familiar with. At one point it was a good idea to look at Excel and Word to know how an Windows application should work; But I don't think that the current versions of Excel and Word are a good model, they deviate too much from the way the OS works. You could still use older versions - before the ribbon, if you are targeting Windows.
It's best to be a bit conservative, choosing applications that have been out for a while and people are likely to be comfortable with rather than chasing the latest design innovations that are coming out of Apple and Microsoft.
I research similar apps and try to follow convention...
E.g. logout goes up in the top right near the "X"/close in most applications
Save/Edit buttons towards the bottom of the thing I'm editing... since contextually they happen after I finish the editing I just did.
Then again, you have apps like Outlook... that have the send/save buttons at the top.
In general though... I have application-wide actions (e.g. login/logout/help user info at the top)
Item specific tend to be inline or just after the item they are adding/editing.
I totally agree with leveraging knowledge that the user already has. Every techie is (or probably is) familiar with http://www.dice.com. It frustrates me to no end to see that their website is designed with the logout "link" (not even a "button") at the very BOTTOM of the page. In this age of security conciousness, what a place to put a logout link ???
I have used DeLorme Street Atlas USA mapping software ever since Windows 3.1. About five or so years ago, they changed their entire user interface, moving AWAY from all of the features that make application software in the Windows environment easy to learn and navigate and SIMILAR from one application to another, and TO a totally foreign user interface, unique to their individual product offering.
Was it necessary ? probably not... What was it's impact to the current user community ? probably not thought about... What was it's impact to someone new to Street Atlas USA ?? Probably LESSENED the adoption rate of the software product, because it looked so foreign compared to a user's already-used applications developed with the common Windows-based look and feel.
Although books can be written on how "we" dislike Microsoft, the value-added benefit to Windows since it's infancy with Windows 3.1 was that you could create totally different software applications, but have a SIMILAR navigation style threaded throughout all of the applications, LESSENING the new application learning curve, and INCREASING the adoption rate amongst software applications for the Windows user.
Leveraging positive current user knowledge can only increase the adoption rate of a software product. Why re-invent the wheel, when the current wheel is known and adequate ?
I think one of the main causes of winrot are the sheer number of services that run at startup (and don't shut down) that phone home every x seconds to see if there is a new version of some piece of software.
Me personally, I disable every single one of them because they seem utterly useless to me. Most of the software packages that use these things, have an option to check for updates whenever you launch the program itself too. This looks way more efficient to me.
I was asking myself what the reason is for companies like Adobe and Apple to create such services that bog clients' computers down and at the same time increase the burden on their own update servers for what looks to me as very little return value for neither of them.
My client requests such a service, but I don't see any reason for it. I want to make sure I'm not missing a piece of the puzzle so I can come back with an educated opinion on why this is should or shouldn't be a desired functionality.
It's usually a desire by management to get brand recognition. It goes something like this:
Oh no. If our program just does its job, the user will never see that it's there, and they'll never find out who we are, and what a great company we are.
We need an icon in the tray; we need a shortcut on the desktop, and in the quick launch toolbar, and at the top level of the Start menu. If we could add a control panel applet, and an item on the right-click menu in Windows Explorer, and an icon in Internet Explorer, that'd be fantastic.
Of course, since our program's so important, the user's going to be using it a lot. Let's add a "speed boost" program that runs at startup, that makes sure that all of our binaries and dependencies are pre-loaded in the cache.
Oh, and we'll need an automated update program, to make sure that all of these components are as wham-bam-great as we can make them.
And can you put a splash screen on that as well?
Can you tell I'm bitter?
Roger's spot on.
Plus, once an application has developed to the point where it already has all the features you could expect it to cover for its intended purpose, the vendor is stuck. They need to keep banging out exciting new versions, so scope bloat creeps in. Instead of doing one thing well and getting out of the way, we must do everything related to it. We must always be in the user's face; they must never be allowed to use software that isn't ours; they must always be interacting with our brand. And of course we must take care to always start an updater task in the background, because we added a completely unnecessary internet-facing browser plugin/toolbar/ActiveX thing that will surely turn out to have security holes.
Acquisitive software is a huge problem that is steadily degrading the user experience on Windows. And it's an arms race: Microsoft hide old application surface interfaces (deprecating the classic start menu, removing quick launch, hiding system tray icons, auto-removing inactive Desktop icons) as they become so full of acquisitive-software junk that they're basically unusable, whilst introducing new ones that "will be better". But how long until applications start "helpfully" adding themselves to the Start menu's MRU list (because you're definitely going to want to use our great software a lot!) and pinning themselves to the Windows 7 dock?
Linux is doing better here because the distros own access to the user and aren't going to put up with any of this crap. Not something Microsoft can get away with though unfortunately.
Bonus Did You Know Fun Fact: Once upon a time, Nero was a nice, elegant CD-burning tool.
Is it worth to try to keep your GUI within the system looks ?
Every major program have their own anyways...
(visual studio, iexplorer, firefox, symantec utilities, adobe ...)
Or just the frame and dialogs should be left in the system look 'n feel range ?
update:
One easy exemple, if you want to add a close button to your tab, usually you make it against your current desktop theme. But if the user has a different theme, your close button is out of place, it doesn't fit the system look anymore.
I played with the uxtheme api, but there is nothing much you can do, and some themes i've seen are incomplete sets.
So to address this issue, the best way i see, is to do like visual studio/firefox/chrome roolup your own tab control with your theme...
I think, that unless your program becomes a very major part of the users life, you should strive to minimize "surprises" and maximimze recognizability (is that even a word?).
So, if you are making something that is used by 1.000 people for 10 minutes a day, go with system looks, and mechanisms.
If, on the other hand, you are making something that 100 people are using for 6 hours a day, I would start exploring what UI improvements and shortcuts I could cram in to make those 6 hours easier to deal with.
Notice however, that UI fixes must not come at the expense of performance. This is almost always the case in the beginning when someone thinks that simply overriding the OnPaint event in .Net will be sufficient.
Before you know it you are once again intercepting NC_PAINT and NC_BACKGROUNDERASE and all those little tricks to make it go as fast as the built-in controls.
I tend to agree with others here- especially Soraz and Smaci.
One thing I'll add, though. If you do feel that the OS L&F is too constraining, and you have good grounds for going beyond it, I'd strive to follow the priciple of "Pacing and leading" (which I'm borrowing here from an NLP context).
The idea is that you still want to capitalise as much as possible on your intended audidences familiarity with the host OS (there will be rare exceptions to this, as Smaci has already covered). So you use as much as possible of the "standard" controls and behaviours (this is the "pacing") - but extend it where necessary in ways that still "fit in" as much as possible (leading).
You've already mentioned some good examples of this principle at work - Visual Studio, even Office to some extend (Office is "special" as new UI styles that cut their teeth here often find their way back into future OS versions - or de-facto standards).
I'm bringing this up to contrast the type of apps that just "do it their way" - usually because they've been ported from another platform, or have been written to be cross-platform in GUI as well as core. Java apps often fall into this category, but they're not the only ones. It's not as bad as it used to be, but even today most pro audio apps have mongrel UIs, showing their lineage as they have been ported from one platform to another through the years. While there might be good business reasons for these examples, it remains that their UIs tend to suck and going this route should be avoided if in any way possible!
The overriding principle is still to follow the path of least surprise, and take account of your user's familiarity with the OS, and ratio of their time using your app to others on the OS.
Yes, if only because it enables the OS to use any accessability features that are built in like text-to-speech. There is nothing more annoying for someone who needs accessability features to have yet another UI that breaks all the tools they are used to.
I'd say it depends on the users, the application and the platform. The interface should be intuitive to the users, which is only the same as following system UI standards if they are appropriate for those users. For example, in the past I have been involved in developing hand held systems for dairy and bread delivery on Windows CE hand helds. The users in this case typically were not computer literate, and had a weak educational backround. The user interface focussed on ease of use through simple language and was modelled on a pre-existing paper form system. It made no attempt to follow the Windows look and feel as this would not have been appropriate.
Currently, I develop very graphical software for a user group that is typically 3rd level educated and very computer literate. The expectation here is that the software will adhere to and extend the Windows look and feel.
Software should be easy and intuitive where possible, and how to achieve this is entirely context dependent.
I'd like to reply with another question (Not really Stackoverflow protocol, but I think that, in this case, it's justified)
The question is 'Is it worth breaking the OS look and feel?'
In other words,
Do you have justification for doing so? (In order to present data in some way that's not possible within normal L&F)
What do you gain from doing so? (Improvinging usability?)
What do you lose from doing so? (Intuitiveness & familiarity?)
Don't simply do it 'To be different'
It depends on how wide you would define system look'n feel... But in general, you should keep it.
Do not surprise the user with differentiating from what he is used to. That's one of the reasons why we call him user ;-)
Firefox and Adobe products usually don't because they are targeting several plattforms which all have their own L&F. But Visual Studio keeps the typical Windows L&F. And, as long as you are developing only for Windows, so should you.
Apart from the fact that there is no well-defined look-n-feel on Windows, you should always try to follow the host platform native L&F. Note however that look-n-feel is just as much about how a program behaves as how it looks. Programs which behave in a counter-intuitive way is just as annoying as programs sporting their own ugly widgets.
Fraps is a good example (IMHO) of a program which is actually very useful, but breaks several user interface guidelines and looks really ugly.
If you're developing for Apple's Mac OS X or Microsoft Windows, the vendors supply interface guidelines which should be followed for any application to be "native".
See Are there any standards to follow in determining where to place menu items? for more information.
If you are on (or develop for) a Mac, then definitely YES!
And this should be true for Windows also.
In general, yes. But there's the occassional program that does well despite being not formatted for all the OSes it runs on. For example, emacs runs pretty much contrary to every interface guideline on OS X or Windows (and probably even gnome/KDE) and it's not going away any time soon.
I strongly recommend making your application look native.
A common mistake that developers who are porting an application to a new platform seem to make is that the new application should look-and-feel like it does on the old platform.
No, the new application should look-and-feel like all the other application that the user is used to on the new platform.
Otherwise, you get abominations like iTunes on Windows. The same UI design may be exactly right on one platform and very wrong on the next.
You will find that your users may not be able to pin-point why they dislike your application, but they just feel it hard to use.
Yes, there are valid exceptions, but they are rare (and sure enough, they tend to be the major applications like Office and Firefox, rather than the little ones). If you are unsure enough to have to ask on StackOverflow, your application isn't one of them.