Integrating OSS Graphics Apps
erikharrison writes "Newsforge had an article recently which proposed an interesting way to make an integrated OSS graphics "suite" - namely, get existing apps to standardize their look and feel. Now, in a short and insightful article, Bryce Harrington (of Inkscape fame) responds with specifics on the advantages and problems with this approach, and where development should go next in the pursuit of a complete OSS stack for graphic artists."
The problem is, you're talking to a crowd who's big complaint about the GIMP UI is that it's not CLI.
The lack of pantone compatibility is a major roadblock. I suggest that the OSS design apps create an open palette plugin format, which would allow users to create and to load in palettes. Then some enterprising soul, who would of course have no connection to the apps themselves, could create a pantone-compatible plugin, which could be downloaded separately from the apps.
This is similar to what happens in the audio world with mp3 encoders.
This newsforge article is directed at the community. That's nice.
The community isn't who needs to hear this. The community already uses these OSS graphics apps.
The people who a suite like this would appeal to are people outside of the community-- people who shop at wal-mart.
The people who need to hear this are businesses.
If some company could have the foresight to gather together the OSS graphics apps, clean them up, tie them together make their interfaces consistent with Mac OS X and Windows UI guidelines, put this all in a nice pretty box, and sell it for $30 at Wal-mart, there's a decent chunk of cash to be had in this. The fact the OSS community has already done all the hard work in developing these applications means you'd be able to offer a very attractive package for a discount-rack price. And the people who would buy something like this wouldn't know how to download and compile software themselves if they wanted to, so they won't mind they're paying for GPLed software.
Just a thought.
-shrug- I know this is heresy to UI wonks, but there are some tasks that are too complex for an idiot-proof interface.
That's not to say that friendly and discoverable interfaces are unattainable, just that making an interface without _any_
learning curve might be unrealistic.
If anybody has achieved this for a featureful graphics-editing application, I haven't seen it yet... Photoshop is
incredibly non-intuitive in my limited experience with it, Paint Shop Pro only slightly less so... but then, I'm just
"used to" the Gimp.
25% Funny, 25% Insightful, 25% Informative, 25% Troll
If, on the other hand, you have to have your graphic designers use several graphics applications, you've got a problem.
You have to make the decision of whether to give them 2-4 disparate applications, each with its own learning curve and quite distinct UIs, or to just give them a handful of Adobe products they already know and use, which are all fairly similar UI-wise.
At some point $1000 worth of software really is cheaper.
1. CMYK and LAB color mode support in GIMP
2. Complete color management support throughout the app
3. High bit depth graphics support - 48 bit and floating point (to stay a bit ahead of Apple/Microsoft).
That's all I want. I couldn't care less about how things look and feel if they do what I want. Well, at least if we're not talking about Mac apps, where look and feel are more important.
We'll never have very rigid standards in anything OSS because, I believe, programmers let their egos get in the way of creating the most usable program possible. They resent the notion of someone telling them how their project should function, and offen interpret any feedback as an attempt to stifle their creativity.
A lot of people like doing things their way, and that's fine! But when we see such fragmentation, forks, redundancy, etc. in OSS projects, we can't be surprised when interoperability is next to impossible.
So if you need to make your project work in a way that only you want it to work, don't be surprised when nobody else uses it.
Socialism: A feeling of discontent and resentment caused by a desire for the possessions or qualities of another.
Use the proper control for the task, and don't clutter your windows. Example: Don't use 2 radio buttons when one checkbox would suffice, don't use more than 5 radio buttons when a combobox would work better.
Also - for God's sake - LINE UP YOUR CONTROLS. If you're a Windows Developer, whether it's VB/C/C++/C#, it's just a matter of laziness to not align your controls. If you're using Java - use a layout manager or a number of layout managers. If you're using GLADE or QtDesigner, take the extra 3 seconds to line up your controls.
Also, tab order should be logical. Focus should go left to right, top to bottom (Arabic and Hebrew - see above). You should also support keystroke shortcut keys that make sense, in fact, if you can make them user definable - do it. Not everyone uses a Qwerty keyboard, and not everyone uses the US character map. Don't make the user move his or her hands unless necessary. Also, right click (or Ctrl-Click) context menus are great - use them.
Finally, some people prefer SDI style apps (OpenOffice.org, IE), others prefer dockable MDI style apps (Visual Studio), and some prefer a collection of floating windows (GIMP). Internally, it's all the same, just each window has a different parent - provide the option to your user. Organize your code properly to handle this from the beginning..
Also - don't pick a color scheme - let the system color it. Same for fonts - that red and green text might look pretty nifty, but to a colorblind person there's no discernable difference. In fact - don't use specific colors at all to convey status. Here in the States, Red means Stop, but this is not true in all cultures. Plus... some people are colorblind. Changing an indicator from green to red is meaningless to them.
This really should be common sense, but I can't tell you how much GUI stupidity I've fixed in my career. Most of it can be attributed to 2 things: laziness, and the GUI done as an afterthought. This is a problem, because while your code may kick all kinds of ass under the hood, if your GUI looks like it was done during amateur hour at the YMCA, the user will think the rest of your app is just as bad.
Also, don't be afraid to consult a graphic designer about your user interface, especially when it comes to icon selection. They excel at conveying that kind of information. Chances are, you have at least one in your marketing department.
It's very easy to spot a bad UI, but a lot harder to actually pin down why its so bad. UI design is hard. It just looks easy.
One of the problems with GIMP is that the toolbar feels very divorced from the wok area. While the X philosophy is that windows just sit there on the desktop, there are better ways of doing this. Why does clicking on a button on the Tools window affect things on the paint window? It's a different window. How many other applications do this? Most X applications don't work like GIMP. Gimp is trying to combine the Photoshop control layout with the X methodology. It would make things easier if they put the controls, work area and menus in the same area as panels. This would work for X. I don't know if its a good solution. Like I said - UI design is hard.
But this is still wrong for Windows. Windows applications use MDI. Consistency is part of good UI design.
There is no need for the interface to be "idiot-proof." It just needs to be good. And there's no task too complex for a good interface.
... it's a lot of stuff.
Consider Final Cut Pro. Editing video is among the more complex tasks people do with computers. Lots of tracks, lots of elements, many transitions, stuff overlapping with other stuff, keys, color corrections, audio effects
Final Cut Pro has one of the best user interfaces for its task. Just the basic way windows work is great. Put two windows next to each other: they snap in place. You can grab the edge between them where they meet and drag it: both windows resize. Arrange four windows so they meet at a common corner, and you can drag just the corner point. All four windows resize.
The net result is that you can change the way the windows are arranged to suit your project and your screen, but you can very easily make maximum use of your screen space. No floating palettes or windows at all, so nothing is ever in your way. And the interface works as well at 1280x1024 as it does at 2560x1600, as well for 2.35:1 content as for 4:3 content.
The user-interface code that makes windows work that way is a framework called ProKit. It's compatible with AppKit, so it's incredibly easy to write programs that take advantage of it. If only Apple would release it as a standalone SDK instead of just using it for their internal products.
Yeah, because copy and paste is so rare compared to how often you need to violently terminate your running app.
-- Too lazy to get a lower UID.
Actually the stupid open dialog is GTK's fault, not the GIMP's. The most recent versions of GTK removed it from the standard dialog.
The only reason Inkscape has a text entry widget in its file dialog was that we very painfully hacked a text input field back into the standard widget using evil methods.
DNA just wants to be free...