Slashdot Mirror
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."
Is getting the GIMP's UI to standardize on "NOT SUCKING"
Get back to me when you've gotten somewhere with that
P.S. Repeating "you're just not used to it" doesn't make UI problems go away. If you can't use a program until you learn to overlook its idiosyncrasities, that's pretty much the *definition* of a bad interface
Each person makes the best possible tool for the application and not stifle creativity or new solutions to the UI by trying to make things "marketable" as a package.
If it's good, users will use it. If it's not, making it part of a suite won't guarantee that they will.
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.
Never (hopefully). Photoshop has a wonderful interface based on L hand on the keyboard and R hand on the mouse. I like it, artists like it, and it works a hell of a lot better than any other complex raster graphics program that I know of.
He even addresses the issue you are berating him for. From the article (titled "Achieving higher consistency between OSS graphics applications"):
-- This post (c) 2003, Knights who say Ni, LTD.
As a frustrated Linux only user, I'm with you. I started in imaging using the gimp and ended up raised thinking it was MEANT to be hard working with pixels.
After years with GIMP I used Photoshop (my sister has a Powerbook). If there's ever a poster boy for the advantages of proprietary software it's photoshop. It's a dream to use, and for the work I do so much faster on smaller hardware than my gimp box. It uses RAM like nobody's business, but then I buy my hardware in the expectation the software will make use of it.
Now I'm still stuck with GIMP on my own box, and finding it harder to justify my use of it by some kind of moral & price advantage when it's really stifling my need for it to work as a graphic tool.
When these apps use standard data formats and simple IPC, we can write our own GUIs (or CLIs) and make them look like they're integrated. Without standard interop, they never will.
--
make install -not war
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.
Stop right there.
Since when was the purpose of Linux to 'supercede' Microsoft? Isn't it enough that Linux already provides a free, open alternative to an inferior operating system?
Socialism: A feeling of discontent and resentment caused by a desire for the possessions or qualities of another.
Wish lists are nice. They let developers know what features they want in a particular project. However, to paraphrase the Wesnoth dev team, "we wrote the program the way we did because that's how we like it. If we use some of your suggestions, it's because we like those, too." These folks write code to scratch their own itch. Scratching YOUR itch is merely a by-product.
Yes, software use and usability is a good thing, but in the end, it comes down to whether coders want to implement it or not.
Cloning: most "users" have a reference point when they use software. People used to windows will find a mac interface foreign and "wrong." Photoshop users will start out not being used to how GIMP works. Same with Word users and OO.org -- just the nature of the game. The real question is: do we have to clone popular interfaces? I suppose. At least maybe some sort of "Photoshop Interface" toggle. Then again you can be a smug developer and say "Use it or not. Go 'way."
Integration: While we're making a list, here's mine:
I want a Quanta that integrates to GIMP which supports editable text mask layers, editable bevel/embossed layers, and that whole color management thing. Integrate that with a managed FTP client thingy kinda like Screem advertises, too. Oh, and integrate that into something that can do Flash animations, too...which will dynamically embed itself onto a Quanta-generated xhtml-valid page. And and and I want a pony!!!
The integration idea is nice. I suppose there's an argument to be made to integrate now and polish later but I think the focus is to make each individual part work well first, then consider integrating later.
You've obviously never used Sodipodi, Inkscape's parent project. Its interface is enough to make mothers abort and milk curdle; it's why Inkscape exists at all.
Before remaking their UI:s and such, please make them at least to _work_ together.
First, make them all handle the same file-formats - i.e. make them handle PNG and SVG. Not just pixmap formats, and not just a buggy SVG-model that can't handle fonts properly, but a fucking working import/export.
Secondly, make copy/paste of non-text data work. Implement something like OLE and make it work in _all_ apps.
An example of a scenario that does not work, but _must_ work: Start out to create a diagram in dia. Export to svg. Import i inkscape. Change some details. Save. Import in kpresenter or OO Impress.
For additional complexity, add some pixmap picture made in GIMP (with variable transparency) to the picture in Inkscape. Perheaps use eps in some steps instaed of svg. Also, you could import the vector-graphics picture as a path in GIMP somewhere in the middle too. Be sure to check that foints work all the way through, even with non-USASCII-characters (We non USAians don't like it when our Ås, Äs and Ös gets mangled to Ãås or =4711 or some other garbage).
When done with this, _then_ I think it would be apropriate to hack on the UI:s to get the a bit more streamlined. But until then, I'd much rather have it just work and look uggly, than not work bu t look great.
--The knowledge that you are an idiot, is what distinguishes you from one.
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.