Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Graphics Software

Integrating OSS Graphics Apps 333

Posted by timothy from the gathering-tide-spreading-cheer dept.
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."
This discussion has been archived. No new comments can be posted.

Integrating OSS Graphics Apps More

Integrating OSS Graphics Apps

Comments Filter:

  • What I think should be focused on first (Score:3, Interesting)

    by Anonymous Coward on Wednesday February 09, 2005 @01:35PM (#11620600)
    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

    • Re:What I think should be focused on first (Score:5, Funny)

      by Anonymous Coward on Wednesday February 09, 2005 @01:38PM (#11620650)
      The problem is, you're talking to a crowd who's big complaint about the GIMP UI is that it's not CLI.

    • Re:What I think should be focused on first (Score:5, Insightful)

      by FauxPasIII ( 75900 ) on Wednesday February 09, 2005 @01:40PM (#11620678)
      -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.
      • Comment removed based on user account deletion

      • Re:What I think should be focused on first (Score:4, Interesting)

        by As Seen On TV ( 857673 ) <asseen@gmail.com> on Wednesday February 09, 2005 @02:24PM (#11621193)
        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.

        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 ... it's a lot of stuff.

        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.
    • Maybe stop complaining and try to do something about it
      Become part of the project.

      Whining all the time will get people down on a project they have spent lto of time on.
      So how about you go to them and say, "This program is great, be here are a couple things that I think should change and this is how I can help."

      Open Source "Community"
      • Well, yeah, I hear that one around these parts a lot. I also hear how he could download the source code, alter it to be the perfect application, just the way he wants, recompile it, and use that instead. But, you know, that's kind of a lot to expect from some random person.

        Maybe he's not a programmer. Maybe the most he has to offer the community is the voice of someone who's displeased with the application. Maybe he's not a UI expert and can't even explain how to make the UI good, and all he can do is

        • I also hear how he could download the source code, alter it to be the perfect application, just the way he wants, recompile it, and use that instead. But, you know, that's kind of a lot to expect from some random person.

          Particularly when there's absolutely no possibility of making a profit from your work. Thanks a lot, Gnu. Ask me again why people aren't tripping over themselves rushing to contribute to your projects?
        • (BTW, this isn't not a complaint about OSS as a whole, but only a rebuttal of the "You don't like it, fix it" attitude expressed by some.)

          How about "you don't like it, don't use it?" I guess the argument against this attitude is that there is so much hype about OSS saying that we SHOULD be using it as a general rule. All I can say is that I, personally, never suggest anyone use OSS if it doesn't fit their needs. GIMP doesn't fit everyone's needs, but it is still a pretty damn nice piece of OSS. Why shoul

          • The argument against that attitude is that if everyone who didn't like the current state of a given OSS project didn't use it, no OSS project would ever grow past the point where it was one person's pet project.

            If you like everything about a project, why try to make it better by contributing?

          • Re:What I think should be focused on first (Score:4, Insightful)

            by nine-times ( 778537 ) <nine.times@gmail.com> on Wednesday February 09, 2005 @03:19PM (#11621865) Homepage
            How about "you don't like it, don't use it?" I guess the argument against this attitude is that there is so much hype about OSS saying that we SHOULD be using it as a general rule.

            That "you don't like it, don't use it!" thing tends to be pretty silly as well. First of all, it's stupidly obvious. If someone's complaining, and when the ask-for-help/offer-criticism, the response they get is rude and insulting, they certainly won't be using that software for very long.

            Plus, it usually appears side-by-side with some statement about, "You're so stupid, I bet you don't even use it, so why are you complaining?!" So... if you use it and you don't like it, stop using it. If you don't use because you don't like it, then you're stupid, so shut up. And all of this comes from the same group who preaches that we all have a moral responsibility to support "FREE (as in speech)" software.

            Listen, user feedback is a valuable way to make your software better. If you don't want to do what it takes to make your software good, then don't try to promote your software, and don't get upset when no one wants to use it. Don't sit back, shooting down user feedback because the users aren't elite enough, and then complain that stupid users aren't using your software.

            Again, this ISN'T a complaint about OSS in general, but only a minority in the community. There is a lot of OSS that is quite good. However, those pieces of software usually come out of a community that is open to user complaints and receptive to input. They clearly were not employing the "If you don't like it, go f$#% yourself," method of customer service.

            Isn't the main complaint about WIndows and many products that run on it that they pander to the lowest common denomonator while simutaneously trying to pack in every concevable bell and whistle?

            "Pandering to the lowest common denominator" and "being responsive to the needs of your users" are two different things.

            Isn't it good enough to say that The GIMP is very powerful and works really well fo the people who use it?

            Well, it's true enough the GIMP is good enough at doing what the people who use it use it to do... but that isn't a very meaningful statement. Are the GIMP developers happy with their small user-base, or would they like to see their program used more widely? Do they want it to be considered a PITA to use by graphic designers, or would they prefer that a Photoshop user sits down in front of the GIMP and says, "Wow, this is nice."

            The GIMP is just an example of something larger that we're talking about, though. The real question is, is OSS just supposed to be something that a small number of geeks tinker with, or is it supposed to be something my mom can use too? If you want my mom to use your software, than you should address the issues my mom will have with your software. If you don't want to do that, then don't be surprised if my mom start talking smack about how your software sucks for what she wants to do. Either way, the whole "holier than thou" attitude isn't impressing her.

      • "Maybe stop complaining and try to do something about it
        Become part of the project."

        Or, if it's really that important that you have a good imaging app, buy Photoshop.

        Buying software is not a sin.
    • Is getting the GIMP's UI to standardize on "NOT SUCKING"

      I'd be interested to see a good discussion of what exactly it is about GIMP's interface that makes it suck. I've seen lots of complaints that "It sucks!" but less in the way of explanations of what the problems actually are. Certainly there are some minor quirks (discoverability of drawing straight lines for instance), but almost all programs as complex as GIMP have similar quirks. Besides, many of those elements are just that: quirks and minor is

      • Re:What I think should be focused on first (Score:4, Interesting)

        by 91degrees ( 207121 ) on Wednesday February 09, 2005 @02:22PM (#11621161) Journal
        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.
      • The problem is with having all the menus in the right click context menu. Most programs have a menu bar where the file menu and other menus reside.

        I'm not sure exactly when right clicking is usefull, but it's certainly annoying when it's used for everything.

        Perhaps the only way out of this dilemma is to have a single mac-like menu bar. Otherwise, the only solution is something like MDI, were the parent window holds the menu bar.

        I suppose you could also put the menu bar on top of each graphic window, but
        • You haven't used the GIMP (or looked at a screenshot [gimp.org] of it) for a very long time, have you?
          • I tried it last week.

            1. I just still can't get over that lack of centralized window. I grew too used to a central window with PSP, Photoshop, Illustrator, and tons of other apps(MDI). I don't want an errant click accidentally clicking on a desktop icon. In Windows, I don't have multi-window desktop like on a typical X installation. Same goes for inkscape

            2. (correct me if I get this wrong), multiple taskbar items. I would be happy with one, and the XP-style stacking is no substitute. Or is that just for in
        • I suppose you could also put the menu bar on top of each graphic window, but that would clutter things up an aweful lot and doesn't seem like a very good solution.
          This very feature is available in Gimp 2.0, and actually it works quite well. People who are still complaining about "everything on the right button" in Gimp need to bring themselves up to date. That argument has been obsolete for quite some time.
    • Is getting the GIMP's UI to standardize on "NOT SUCKING"

      In case anyone is skeptical, I'll just point out two minor ways that The GIMP's UI sucks:

      The "Open File" dialog box has no text-input field. That's right, there's no place for you to type in the file you want. A knowledgable person could pop up a separate mini-window to type in a filename (which will then be lacking a scrollable list of files & folders), or do a type-ahead search, but neither of those options justifies removing the simple tex

      • Re:What I think should be focused on first (Score:5, Informative)

        by MenTaLguY ( 5483 ) on Wednesday February 09, 2005 @03:53PM (#11622287) Homepage
        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.
      • The open & save dialogs are part of the GTK / GNOME project, not GIMP. And why would anyone want to dock a toolbar to a specific image window when they can have one dock (the main toolbox) to one side and use that for everything?
      • If I knew anything about GTK or GUI programming in general I would be glad to write a function for GIMP to "eat" all it's windows and provide a PSP7 style interface where the app is a window and all dialogs, menus, and open files stay inside it. Personally I like the current interface for GIMP but it was a bit scary to learn and many do have trouble with it.
    • If you can't use a program until you learn to overlook its idiosyncrasities, that's pretty much the *definition* of a bad interface

      Well I guess that makes the mouse a bad interface.

      And a pencil and paper too, for that matter.

      Hate to break it to you, dude, but it's all learned.

    • Is getting the GIMP's UI to standardize on "NOT SUCKING"

      I'm reminded of Stan Kelly-Bootle's humorous example of an algorithm... in pseudocode rather than the original flowchart, here's SKB's "algorithm" for maximizing human happiness:

      while (human happiness can be increased)
      increase human happiness;

      The joke, of course, is that it's not an algorithm at all; the steps are all utterly ill-defined.

      Making the GIMP's UI not suck is a worthy goal. Care to specify in detail what currently sucks about it
    • It could be worse. It could be Lotus Notes-- and that's an application with a huge corporation that should know better behind it.

      It's amazing how a single year of using Lotus Notes suddenly changes your perspective on what a "bad" user interface is. Talk about lowering the bar.

  • How about... (Score:4, Interesting)

    by Gruneun ( 261463 ) on Wednesday February 09, 2005 @01:37PM (#11620629)
    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.

    • Re:How about... (Score:3, Interesting)

      by KiltedKnight ( 171132 )
      That's what I've always liked about X. You just need to choose a window manager based on features, etc, which you then can configure certain behavioral aspects plus appearance.

      As long as your window manager conforms to the necessary standards, you're free to pick and choose what you like.

    • He's not talking about marketability, but rather consistency and interoperability.

      He even addresses the issue you are berating him for. From the article (titled "Achieving higher consistency between OSS graphics applications"):

      This is often mentioned as establishing a "suite", however I think what is desired is more about establishing ourselves as a "team". To me, a "suite" conjures up the notion of corporate software giants bundling applications together to try to kill off the competition.

      • Thanks, I did. You miss my point.

        The moment you require consistency, you introduce constraints. Constraints limit creativity. If a standard exists, it should be a result of evolution, not mandate. If the goal is to influence people to use certain applications together, you can call it whatever you want... it's still marketing.

        Besides, the simple fact that OSS developers release their applications and code for free use already makes them a tight team.
        • If a standard exists, it should be a result of evolution, not mandate.

          Where do you get your "should"? A casual observer of the US cellular telephone industry would tell you what a horrible mess it has been, with multiple incompatible standards forcing duplicated coverage efforts. This results in a lot of money wasted, and a lot of customers frustrated.

          In some cases, most notably where the alternatives do not differ greatly, a dictated standard is better than not having any at all. (This should be easy t

    • Re:How about... (Score:4, Insightful)

      by Inkieminstrel ( 812132 ) on Wednesday February 09, 2005 @01:46PM (#11620760) Homepage
      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.

    • Re:How about... (Score:3, Interesting)

      by nine-times ( 778537 )
      You have a point, but it also shows a certain disregard for the way designers work. When you're working on something, (using Adobe's apps as an example) there's a good chance that you're not going to use *just* Photoshop or *just* Illustrator or *just* InDesign. There's a good chance you'll use all of them at different points during the same project, so while you want each program's interface to be optimized for their individual tasks, you also want some continuity between GUIs so that you don't have to "

  • palette plugins (Score:4, Interesting)

    by soupdevil ( 587476 ) on Wednesday February 09, 2005 @01:39PM (#11620663)
    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.

  • What I'm waiting for someone to figure out (Score:4, Insightful)

    by Anonymous Coward on Wednesday February 09, 2005 @01:40PM (#11620672)
    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.

  • Oooh!! OOOH!! Mista Kotter! (Score:3, Funny)

    by DwarfGoanna ( 447841 ) on Wednesday February 09, 2005 @01:41PM (#11620697)
    Can we call it oLife?!


    =)

  • Why do they want them to standardize? (Score:3, Funny)

    by Transcendent ( 204992 ) on Wednesday February 09, 2005 @01:47PM (#11620773)
    ...namely, get existing apps to standardize their look and feel.

    ...so they can just copy exactly what some other program is doing, and the OSS designers don't have to be innovative or creative on their own? Come on now, do you own work...

    Why would you want a standard interface anyway (No, I didn't RTFA)?? That would be absolutely horrible if any major (or even minor) advances, tweaks, changes, etc are made... you're still stuck in an outdated "standard" that probably won't apply to whatever you came up with. Even if you update the "standard", that's just wasting needless time.
    • Let me see if I understand you. You don't want to read the article, but you feel perfectly comfortable dismissing its premise outright while demanding that other people defend it to you?

      Read the article, THEN you can tell me why it's a bad idea.
      • I never demanded that people defend it... there's always an "ignore" option in life. I just think that standardizing an interface for a graphical application (besides the general sense for management in the parent environment) is bad and will reduce user efficiency.

        Can you tell me that a photoshop (or GIMP) interface will work great for photo editing, or 3D design?

        Sure the OSS community might benefit from having a standard in terms of a learning curve for each application, but the usability and efficiency
    • ...so they can just copy exactly what some other program is doing, and the OSS designers don't have to be innovative or creative on their own? Come on now, do you own work...

      Yeah, I know. I heard Honda will be coming out with a new car in a couple years... but it'll be using WHEELS and an ENGINE! I heard they're even going to use FUEL of some kind! What's the point of just copying other car designs, huh? That's not innovative. There's nothing creative about a car with wheels.

      That would be absolutely

    • so they can just copy exactly what some other program is doing, and the OSS designers don't have to be innovative or creative on their own?
      RTFA. They're talking about wanting the GIMP, Inkscape, etc. to be consistent with each other, not to copy Adobe! The goal is simply to create a good workflow. Do you have a problem with that, troll?
    • ..so they can just copy exactly what some other program is doing, and the OSS designers don't have to be innovative or creative on their own? Come on now, do you own work...

      Why should every project reinvent the wheel? Isn't one of the advantages of OSS the fact you don't have to re-implement what has already been done.

      • Isn't one of the advantages of OSS the fact you don't have to re-implement what has already been done.

        Your point is moot when half the OSS programmers have a Not-Invented-Here attitude. This would explain why there (for example) a thousand open-source CMS systems that all do pretty much the same thing in a slightly different and just as confusing way.
        • I am very aware of this trend in OSS. I think the original poster illustrates it well. Nevertheless, it is an advantage that exists, whether or not anyone actually takes advantage of it. I think OSS needs to lose the "Not-Invented-Here" attitude and start exploiting every strong point they have-- pride be damned.

  • Standards and IPC (Score:4, Insightful)

    by Doc Ruby ( 173196 ) on Wednesday February 09, 2005 @01:55PM (#11620867) Homepage Journal
    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.
    • Just to expand on that point a bit. Command-line interfaces are not IPC. Application and library developers need to create C interfaces to their apps, not command-lines.

  • Do this first: (Score:5, Informative)

    by melted ( 227442 ) on Wednesday February 09, 2005 @01:56PM (#11620880) Homepage
    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.

  • Ummmm how far is this likely to go? (Score:3, Insightful)

    by ShatteredDream ( 636520 ) on Wednesday February 09, 2005 @01:57PM (#11620889) Homepage
    The competition from Adobe and Macromedia is already tremendously robust on a level that in a 1:1 competition between say GIMP and Photoshop that the OSS apps can scarcely approach the level of functionality that their commercial competitors can. We are talking about very well-financed, extremely aggressive competitors here, not lumbering monoliths that can only succeed half the time by pulling on past successes.

    It's worth doing, but no one should get their hopes up that Adobe or Macromedia will be phased by this. They are simply too good at what they do to be caught up in the same software vietnam that Microsoft has found itself in with Linux, Apache, OpenOffice and Mozilla.

  • Standards Conflicting with Egos (Score:4, Insightful)

    by Trolling4Columbine ( 679367 ) on Wednesday February 09, 2005 @01:57PM (#11620891)
    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.
    • 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.

      Wah, wah, wah! Quit whining. These people are working for free to give you software. You should be grateful.

      A lot of people like doing things their way, and that's fine! But when we see suc

      • Wah, wah, wah! Quit whining. These people are working for free to give you software. You should be grateful.

        I'm never grateful for stuff I can't use and if they want me to use it they should be open to feedback from me. And no, I can't specify who "they" are any more than to say that they're the same "These people" you're referring to.

        There is plenty of interoperability. Maybe it isn't all polished and marketable as you would like, but there is interoperability galore in the form of starndard file for

  • Proper GUI Design (Score:5, Insightful)

    by RailGunner ( 554645 ) on Wednesday February 09, 2005 @01:59PM (#11620922) Journal
    Proper GUI design, at it's core, is really a matter of widget selection and placement. When displaying things to the user, keep things left to right, and top to bottom (reverse for Arabic and Hebrew - in other words, KNOW YOUR TARGET AUDIENCE).

    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.

    • Not enough (Score:3, Insightful)

      by TuringTest ( 533084 )
      What you describe is low-level GUI management, the kind of what is solved by following some GUI guidelines (like GNOME Human Interface Guidelines [gnome.org], for instance). It's certainly the kind of details that a programmer should know, but it is not enough to build a decent interface.

      The core of a really good application is goal oriented software design (also called user oriented design). Before thinking about widgets and gadgets and frame layout, you should start by defining what the application must do and how t
    • context menus are great - use them.
      just a nit pick on this one. you should always provide a way to access something using a context menu without having to right click (such as in the top menu like in mac os).
    • Also - don't pick a color scheme - let the system color it. .... Here in the States, Red means Stop, but this is not true in all cultures. Plus... some people are colorblind.


      WARNING!!!! Format the hard drive???

      [ Big RED Button ]
      [ Big GREEN Button ]




      Does RED mean cancel and GREEN mean go ahead?

      Or does RED mean do the dangerous operation, and GREEN means safely skip doing it?

      Red can mean stop or danger. Green can mean go or safety. In some cases, go = danger, and stop = safety.


      Lesson
      • This is why any sort of decent interface would have the words "YES" and "NO" as responses to the question and not colored buttons...

        Also, yes/no questions should have buttons with yes/no answers on them, not "OK" and "Cancel"
        • It's amazing to me how many games over the years use just random colors to indicate this or that. Often you don't get a clear red or green to indicate what you chose. Sometimes you get a ligher/darker shade of a color combo, or just 2 random colors. bad dialog!
        • Actually, in this case, I would strongly suggest that the buttons are made "action oriented" -- that you write "Format" and "Cancel" on them. Having "Yes" and "No" makes it easier to do a mistake due to misreading the question.
    • Proper GUI design, at it's core, is really a matter of widget selection and placement.

      Proper creative writing, at it's core, is really a matter of word selection and placement.

      Proper bio-engineering, at it's core, is really a matter of molecule selection and placement.

      Why, THANK YOU for that tremendous insight!

  • Wish Lists, Cloning, and Integration (Score:3, Interesting)

    by Eberlin ( 570874 ) on Wednesday February 09, 2005 @02:05PM (#11620973) Homepage
    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.

    • 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."

      That is exactly what we did. We offer a far more powerful interface, mouse-wise, than Photoshop does. And of course, that means it is quite different in how it handles. We put in an "operates like Photoshop" mode so that those who were not willing to consider the method we chose would not have that as a reason to dismiss our software out of hand, and so that we could continu

  • As a professional artist and MFA candidate, I can say that there are a few things I'd look for in an OSS suite:
    1. It can open photoshop, illustrator, and quark Xpress formats. You wouldn't be surprised how many people use those formats...

    2. I agree with standard cut+paste, and I would go further to say standardized "layers", and at least the buttons looking similar, i.e. a little paintbrush is the standard paintbrush-type feature, not some random crap in one place and some other random crap in another p
  • Close to 1 year ago, I conducted an extensive test of clipboard compatibility between the major Free Software desktop applications. (OpenOffice, Mozilla, KDE Office, Abiword, Gnumeric, and The Gimp). Scores were dismal, especially for The Gimp, which usually appeared to be using a clipboard system completely disjoint from the other applications.

    Quick retests conducted today, using the newer 2.0 GIMP series, show tremendous improvement.

    Today, The GIMP is capable of accepting graphics pasted from Kword, O
  • I think this was the most insightful comment on FOSS interoperability I have read in a long long time. It is refreshing to read an opinion that does not focus on language and toolkit differences. Even though - the suggestion for projects to develop sharable building blocks in the form of reusable APIs is very good. I think that is a slow, but certain way to increase interoperability over time - between the subset of applications developed with the same language.

    If these APIs then work against common specif

  • Integrate copy-paste first (Score:4, Insightful)

    by redhog ( 15207 ) on Wednesday February 09, 2005 @02:42PM (#11621424) Homepage
    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.
  • Instead of trying to get all these separate apps to agree on a single UI, script it.

    Write the UI portion of the application in Python/Perl/whatever such that a user can drop in someone else's UI.

    Clicking on a button would call into the C/C++ within the app to actually do the work. The scripting language would just layout the UI and respond to the user.

    Then if someone wants a 'common' UI among the apps, they can make it themselves. No need to get the GIMP developers to agree with anyone else's UI philos

  • Interface for Artists IS Inconsistent (Score:3, Insightful)

    by buckhead_buddy ( 186384 ) on Wednesday February 09, 2005 @04:40PM (#11622845)
    User interfaces for artists are, by definition, inconsistent. Are watercolors or acrylics a "better" interface for painiting? Will one produce a "truer" work with synthetic or natural modelling clays?

    Warnock's Postscript was an amazing technical creation; I think it deserves its success over its page description competitors. Adobe also kept the Type 1 font hinting as their special technical secret about creating great fonts.

    You'd expect Adobe's font creation tools, and vector graphic tools to monopolize their marketplaces. They don't.

    Macromeida's Typographer dominates the "hinted font" market. And Corel Draw and Macromedia Freehand are solid competitors for Adobe's Illustrator almost solely distinguished by the look and feel of their user interfaces.

    Page layout tools are a different area where Adobe has tried to buy its way into the market (Buying Aldus PageMaker) and use its weight to change the standards (PDF and FrameMaker). The suprise is that they haven't been more successful than they have been so far. While there are all sorts of legacy issues in this area, the extreme stinkiness of FrameMaker 1.0's user interface turned a lot of people off to their toolset.

    And then the big suprise was the fantastic success of Adobe's Photoshop. There was nothing particularly spectactular technically about the bitmap files they were producing. But the amazing look and feel the Knolls' imbued in the user interface is what made this tool the success it was. The filter specs didn't offer anything much better than Pixel Paint or most other bitmap tools, but the sub-pixel look and feel of the tools gave Photoshop its anti-aliasing edge.

    Personally, I think this standards war may already be too far lost. I'd look into something else. Suites of tools for school teachers or librarians. Something where there's a definite technical aspect, but where the personal touch can go a LONG way toward distinguishing and defining what people demand in their tools. I think artists may have already had these battles fought. While I'm not arguing about giving up, other areas might be more open toward wooing.

Slashdot Top Deals

How many NASA managers does it take to screw in a lightbulb? "That's a known problem... don't worry about it."

Close