Loading ...
Sorry, an error occurred while loading the content.

Linux interface library documentation

Expand Messages
  • Dave Cronin
    Hi All, I m wondering if anyone can point me in the direction of any resources about Linux presentation layer standards. I m pretty new to Linux and any
    Message 1 of 10 , Oct 5, 2004
    • 0 Attachment
      Hi All,

      I'm wondering if anyone can point me in the direction of any resources about Linux presentation layer standards. I'm pretty new to Linux and any materials would be helpful. In particular I'm interested in what aspects are customizable/controllable, and what are system determined.

      Thanks,
      dave
    • William Pietri
      ... Hi, Dave. If I understand your question rightly, you re looking for something like Apple s Human Interface Guidelines for Linux. Is that correct? I have
      Message 2 of 10 , Oct 5, 2004
      • 0 Attachment
        On Tue, 2004-10-05 at 07:50, Dave Cronin wrote:
        > Hi All,
        >
        > I'm wondering if anyone can point me in the direction of any resources
        > about Linux presentation layer standards. I'm pretty new to Linux and
        > any materials would be helpful. In particular I'm interested in what
        > aspects are customizable/controllable, and what are system determined.

        Hi, Dave. If I understand your question rightly, you're looking for
        something like Apple's Human Interface Guidelines for Linux. Is that
        correct?

        I have never heard of anything like that. The core windowing system,
        X11, is notorious for having no standards of any sort. The best bet
        would be that one of the Desktop/GUI-Toolkit efforts, like GNOME or KDE
        would have something. However, at least as RedHat ships them, they both
        end up working and acting a lot like Windows.

        As to what's customizable and controllable, the answer is that if you're
        willing to go deep enough, nearly everything. Otherwise, it completely
        depends on what language and GUI toolkits you decide to use. The most
        common choices these days are GNOME and KDE; their sites may be a good
        place to start:

        http://www.gnome.org/
        http://www.kde.org/

        William
      • Petteri Hiisilä
        ... Yeah, GNOME nd KDE are both used a lot, and they are quite similar from the user experience point of view. I wouldn t consider any other environment. The
        Message 3 of 10 , Oct 5, 2004
        • 0 Attachment
          > As to what's customizable and controllable, the answer is that if you're
          > willing to go deep enough, nearly everything. Otherwise, it completely
          > depends on what language and GUI toolkits you decide to use. The most
          > common choices these days are GNOME and KDE; their sites may be a good
          > place to start:
          >
          > http://www.gnome.org/

          Yeah, GNOME nd KDE are both used a lot, and they are quite similar from
          the user experience point of view. I wouldn't consider any other
          environment. The rest of them will only please so called "power users".

          GNOME and KDE will both serve you fine, but if you have to choose one,
          take GNOME: it's the default environment in the most popular Linux
          distributions. My personal opinion doesn't favor either one of them.
          They're both OK.

          I believe that you can run KDE applications in GNOME environment and
          vice versa, if you've installed both in your machine.

          GNOME screen shots:
          http://ftp.gnome.org/pub/GNOME/teams/marketing/en/2004/two-eight-screenshots/html/index.html

          KDE screen shots:
          http://www.kde.org/screenshots/

          ***

          Take a look at this: http://developer.gnome.org/projects/gup/hig/

          "GNOME Human Interface Guidelines

          This document tells you how to create applications that look right,
          behave properly, and fit into the GNOME user interface as a whole. It is
          written for interface designers, graphic artists and software developers
          who will be creating software for the GNOME environment. Both specific
          advice on making effective use of interface elements, and the philosophy
          and general design principles behind the GNOME interface are covered.

          These guidelines will help you write applications that are easy to use
          and consistent with the GNOME desktop. Following these guidelines will
          have many benefits:

          Users will learn to use your program faster, because interface elements
          will look and behave the way they are used to.

          Novice and advanced users alike will be able accomplish tasks quickly
          and easily, because the interface won't be confusing or make things
          difficult.

          Your application will have an attractive look that fits in with the rest
          of the desktop.

          Your application will continue to look good when users change desktop
          themes, fonts and colors.

          Your application will be accessible to all users, including those with
          disabilities or special needs.

          To help you achieve these goals, these guidelines will cover basic
          interface elements, how to use them and put them together effectively,
          and how to make your application integrate well with the desktop.

          The recommendations here build on design aspects that have worked well
          in other systems, including Mac OS, Windows, Java and KDE. At the same
          time they retain a uniquely GNOME flavor."

          - Petteri

          --
          Petteri Hiisilä
          Palveluarkkitehti / Interaction Designer /
          Alma Media Interactive Oy / NWS /
          +358505050123 / petteri.hiisila@...

          "I was told there's a miracle for each day that I try"
          - John Petrucci
        • Petteri Hiisilä
          ... KDE has it s own style guide: http://developer.kde.org/documentation/standards/kde/style/basics/index.html This document attempts to specify the
          Message 4 of 10 , Oct 5, 2004
          • 0 Attachment
            >
            > KDE screen shots:
            > http://www.kde.org/screenshots/
            >

            KDE has it's own style guide:

            http://developer.kde.org/documentation/standards/kde/style/basics/index.html

            "This document attempts to specify the look-and-feel for KDE
            applications. The goal is to provide some rules-of-thumb for developers
            to create their applications interface so that KDE software will have a
            consistent look-and-feel.

            The guidelines in this style guide are only suggestions - they are not
            set in stone. It is the application designer's duty to create a decent
            interface. Following rules will not do that, but common sense will.

            These guidelines are aimed at a typical application consisting of a
            menubar, toolbar, working area and statusbar. Not every application
            necessarily needs to have all these components, but if your application
            does, then the components should work as described here. Please note
            that not every component described must be present in your application."

            - Petteri
          • Mike Kuniavsky
            KDE also has UI Guidelines: http://developer.kde.org/documentation/design/ui/ I can t vouch for their quality, but when I was reviewing guidelines for a client
            Message 5 of 10 , Oct 5, 2004
            • 0 Attachment
              KDE also has UI Guidelines:

              http://developer.kde.org/documentation/design/ui/

              I can't vouch for their quality, but when I was reviewing guidelines for a
              client project recently, I looked at them and they seemed, well, rough
              around the edges, but better than nothing.

              My realization, helped by some of the comments made in this group, is that
              UI guidelines aren't really followed if they're presented as rules that
              require extra work on the part of the developer. This is particularly
              obvious in the Open Source world, since other than self-motivation there
              are pretty much no incentives for developers to follow any rules at all
              that make things harder. So they don't, and apart from some islands of
              consistency (which GNOME and KDE attempt to be), it's pretty random out
              there.

              I think that Apple's solution is very good: have lots of rules, but make
              tools that make it easier to follow those rules than to not follow them.
              (it leverages Larry Wall's Three Great Virtues of a Programmer:
              Laziness, Impatience and Hubris) The Apple toolbox and Interface Builder
              enforce many of the rules, even if you haven't read them. That's of course
              only more or less true--using the Apple toolbox was not a picnic the last
              time I did any Mac programming (more than 10 years ago)--but I like the
              philosophy behind it. I also understand that the new Interface Builder is
              pretty cool, though I haven't used it.

              On Tue, 5 Oct 2004, [ISO-8859-1] Petteri Hiisilä wrote:

              > > As to what's customizable and controllable, the answer is that if you're
              > > willing to go deep enough, nearly everything. Otherwise, it completely
              > > depends on what language and GUI toolkits you decide to use. The most
              > > common choices these days are GNOME and KDE; their sites may be a good
              > > place to start:
              > >
              > > http://www.gnome.org/
              >
              > Yeah, GNOME nd KDE are both used a lot, and they are quite similar from
              > the user experience point of view. I wouldn't consider any other
              > environment. The rest of them will only please so called "power users".
              >
              > GNOME and KDE will both serve you fine, but if you have to choose one,
              > take GNOME: it's the default environment in the most popular Linux
              > distributions. My personal opinion doesn't favor either one of them.
              > They're both OK.
              >
              > I believe that you can run KDE applications in GNOME environment and
              > vice versa, if you've installed both in your machine.
              >
              > GNOME screen shots:
              > http://ftp.gnome.org/pub/GNOME/teams/marketing/en/2004/two-eight-screenshots/html/index.html
              >
              > KDE screen shots:
              > http://www.kde.org/screenshots/
              >
              > ***
              >
              > Take a look at this: http://developer.gnome.org/projects/gup/hig/
              >
              > "GNOME Human Interface Guidelines
              >
              > This document tells you how to create applications that look right,
              > behave properly, and fit into the GNOME user interface as a whole. It is
              > written for interface designers, graphic artists and software developers
              > who will be creating software for the GNOME environment. Both specific
              > advice on making effective use of interface elements, and the philosophy
              > and general design principles behind the GNOME interface are covered.
              >
              > These guidelines will help you write applications that are easy to use
              > and consistent with the GNOME desktop. Following these guidelines will
              > have many benefits:
              >
              > Users will learn to use your program faster, because interface elements
              > will look and behave the way they are used to.
              >
              > Novice and advanced users alike will be able accomplish tasks quickly
              > and easily, because the interface won't be confusing or make things
              > difficult.
              >
              > Your application will have an attractive look that fits in with the rest
              > of the desktop.
              >
              > Your application will continue to look good when users change desktop
              > themes, fonts and colors.
              >
              > Your application will be accessible to all users, including those with
              > disabilities or special needs.
              >
              > To help you achieve these goals, these guidelines will cover basic
              > interface elements, how to use them and put them together effectively,
              > and how to make your application integrate well with the desktop.
              >
              > The recommendations here build on design aspects that have worked well
              > in other systems, including Mac OS, Windows, Java and KDE. At the same
              > time they retain a uniquely GNOME flavor."
              >
              > - Petteri
              >
              > --
              > Petteri Hiisilä
              > Palveluarkkitehti / Interaction Designer /
              > Alma Media Interactive Oy / NWS /
              > +358505050123 / petteri.hiisila@...
              >
              > "I was told there's a miracle for each day that I try"
              > - John Petrucci
              >
              >
              > Yahoo! Groups Sponsor
              > ADVERTISEMENT
              > click here
              > [rand=560065435]
              >
              > ________________________________________________________________________________________________________
              > Yahoo! Groups Links
              > * To visit your group on the web, go to:
              > http://groups.yahoo.com/group/agile-usability/
              >
              > * To unsubscribe from this group, send an email to:
              > agile-usability-unsubscribe@yahoogroups.com
              >
              > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
              >
              >

              --
              Mike Kuniavsky
              mikek@...
            • Dave Cronin
              Thanks all. I knew there wouldn t be one unified standard (that s fairly against the grain of the whole point of Linux, eh ;), but was interested to see what
              Message 6 of 10 , Oct 5, 2004
              • 0 Attachment
                RE: [agile-usability] Paper prototyping in movies, video games?

                Thanks all.

                 

                I knew there wouldn’t be one unified standard (that’s fairly against the grain of the whole point of Linux, eh ;), but was interested to see what work had been done in that direction.

                 

                These look like a good place to start.

                 

                -dave

              • Bayley, Alistair
                There is also a combined effort, of sorts: http://www.freedesktop.org Although it s not specifically usability focused. ...
                Message 7 of 10 , Oct 6, 2004
                • 0 Attachment
                  There is also a combined effort, of sorts:
                  http://www.freedesktop.org

                  Although it's not specifically usability focused.


                  > GNOME screen shots:
                  >
                  http://ftp.gnome.org/pub/GNOME/teams/marketing/en/2004/two-eight-screenshots
                  /html/index.html
                  >
                  > KDE screen shots:
                  > http://www.kde.org/screenshots/
                  >
                  > Take a look at this: http://developer.gnome.org/projects/gup/hig/
                  >

                  -----------------------------------------
                  *****************************************************************
                  Confidentiality Note: The information contained in this
                  message, and any attachments, may contain confidential
                  and/or privileged material. It is intended solely for the
                  person(s) or entity to which it is addressed. Any review,
                  retransmission, dissemination, or taking of any action in
                  reliance upon this information by persons or entities other
                  than the intended recipient(s) is prohibited. If you received
                  this in error, please contact the sender and delete the
                  material from any computer.
                  *****************************************************************
                • Michael Mahemoff (Mailing Lists)
                  This is an interesting point about tools - I have found there are several steps a platform s facilitator can take to promote UI guidelines flourish across the
                  Message 8 of 10 , Oct 6, 2004
                  • 0 Attachment
                    This is an interesting point about tools - I have found there are
                    several steps a platform's facilitator can take to promote UI guidelines
                    flourish across the community. I did some research on style guides a
                    while back, and a few success factors were:

                    * The concepts. Most importantly, the concepts have to be logical and
                    fit together cohesively. No good having one guideline suggest "3D never"
                    and another suggest "raise/lower buttons".
                    * The style guide document. Being a document, no-one will read it. Or
                    not often anyway. However, its presentation and structure are important
                    as it will be consulted as a reference. And it will be used for tools
                    and example applications.
                    * Tools. Like you say. HTML Templates, for instance. Also, non-invasive
                    "critics" - like MS Word's underlining and Eclipse/Idea lightbulbs -
                    which indicate potential issues and help you resolve them. I can't
                    recall any UI toolkits that do this, but it would be nice?
                    * EXAMPLES. Vital to have archetypal applications that the whole
                    community can identify with and work from. MS does this every time with
                    Office. I'd be willing to bet 100 times more developers base their
                    design on MS-Word than on the MS style guide.

                    The KDE standards document
                    http://developer.kde.org/documentation/standards/kde/style/basics/index.html
                    is very lucid and sufficiently thorough as a style guide. In the case of
                    both Gnome and KDE, specialised development tools are unlikely because
                    of the diversity of development environments - each have libraries in so
                    many languages, and there is no official or de facto standard, a la
                    Visual Studio. Archetypal applications? Not to the same extent as
                    MS-Office, but there are applications like konqueror and koffice that
                    developers can base their work on.

                    Michael Mahemoff
                    J2EE Developer/Architect
                    http://mahemoff.com

                    Mike Kuniavsky wrote:

                    > KDE also has UI Guidelines:
                    >
                    > http://developer.kde.org/documentation/design/ui/
                    >
                    > I can't vouch for their quality, but when I was reviewing guidelines for a
                    > client project recently, I looked at them and they seemed, well, rough
                    > around the edges, but better than nothing.
                    >
                    > My realization, helped by some of the comments made in this group, is that
                    > UI guidelines aren't really followed if they're presented as rules that
                    > require extra work on the part of the developer. This is particularly
                    > obvious in the Open Source world, since other than self-motivation there
                    > are pretty much no incentives for developers to follow any rules at all
                    > that make things harder. So they don't, and apart from some islands of
                    > consistency (which GNOME and KDE attempt to be), it's pretty random out
                    > there.
                    >
                    > I think that Apple's solution is very good: have lots of rules, but make
                    > tools that make it easier to follow those rules than to not follow them.
                    > (it leverages Larry Wall's Three Great Virtues of a Programmer:
                    > Laziness, Impatience and Hubris) The Apple toolbox and Interface Builder
                    > enforce many of the rules, even if you haven't read them. That's of course
                    > only more or less true--using the Apple toolbox was not a picnic the last
                    > time I did any Mac programming (more than 10 years ago)--but I like the
                    > philosophy behind it. I also understand that the new Interface Builder is
                    > pretty cool, though I haven't used it.
                    >
                    > On Tue, 5 Oct 2004, [ISO-8859-1] Petteri Hiisil� wrote:
                    >
                    >
                    >>>As to what's customizable and controllable, the answer is that if you're
                    >>>willing to go deep enough, nearly everything. Otherwise, it completely
                    >>>depends on what language and GUI toolkits you decide to use. The most
                    >>>common choices these days are GNOME and KDE; their sites may be a good
                    >>>place to start:
                    >>>
                    >>> http://www.gnome.org/
                    >>
                    >>Yeah, GNOME nd KDE are both used a lot, and they are quite similar from
                    >>the user experience point of view. I wouldn't consider any other
                    >>environment. The rest of them will only please so called "power users".
                    >>
                    >>GNOME and KDE will both serve you fine, but if you have to choose one,
                    >>take GNOME: it's the default environment in the most popular Linux
                    >>distributions. My personal opinion doesn't favor either one of them.
                    >>They're both OK.
                    >>
                    >>I believe that you can run KDE applications in GNOME environment and
                    >>vice versa, if you've installed both in your machine.
                    >>
                    >>GNOME screen shots:
                    >>http://ftp.gnome.org/pub/GNOME/teams/marketing/en/2004/two-eight-screenshots/html/index.html
                    >>
                    >>KDE screen shots:
                    >>http://www.kde.org/screenshots/
                    >>
                    >>***
                    >>
                    >>Take a look at this: http://developer.gnome.org/projects/gup/hig/
                    >>
                    >>"GNOME Human Interface Guidelines
                    >>
                    >>This document tells you how to create applications that look right,
                    >>behave properly, and fit into the GNOME user interface as a whole. It is
                    >>written for interface designers, graphic artists and software developers
                    >>who will be creating software for the GNOME environment. Both specific
                    >>advice on making effective use of interface elements, and the philosophy
                    >>and general design principles behind the GNOME interface are covered.
                    >>
                    >>These guidelines will help you write applications that are easy to use
                    >>and consistent with the GNOME desktop. Following these guidelines will
                    >>have many benefits:
                    >>
                    >>Users will learn to use your program faster, because interface elements
                    >>will look and behave the way they are used to.
                    >>
                    >>Novice and advanced users alike will be able accomplish tasks quickly
                    >>and easily, because the interface won't be confusing or make things
                    >>difficult.
                    >>
                    >>Your application will have an attractive look that fits in with the rest
                    >>of the desktop.
                    >>
                    >>Your application will continue to look good when users change desktop
                    >>themes, fonts and colors.
                    >>
                    >>Your application will be accessible to all users, including those with
                    >>disabilities or special needs.
                    >>
                    >>To help you achieve these goals, these guidelines will cover basic
                    >>interface elements, how to use them and put them together effectively,
                    >>and how to make your application integrate well with the desktop.
                    >>
                    >>The recommendations here build on design aspects that have worked well
                    >>in other systems, including Mac OS, Windows, Java and KDE. At the same
                    >>time they retain a uniquely GNOME flavor."
                    >>
                    >> - Petteri
                    >>
                    >>--
                    >>Petteri Hiisil�
                    >>Palveluarkkitehti / Interaction Designer /
                    >>Alma Media Interactive Oy / NWS /
                    >>+358505050123 / petteri.hiisila@...
                    >>
                    >>"I was told there's a miracle for each day that I try"
                    >> - John Petrucci
                    >>
                    >>
                    >>Yahoo! Groups Sponsor
                    >>ADVERTISEMENT
                    >>click here
                    >>[rand=560065435]
                    >>
                    >>________________________________________________________________________________________________________
                    >>Yahoo! Groups Links
                    >> * To visit your group on the web, go to:
                    >> http://groups.yahoo.com/group/agile-usability/
                    >>
                    >> * To unsubscribe from this group, send an email to:
                    >> agile-usability-unsubscribe@yahoogroups.com
                    >>
                    >> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                    >>
                    >>
                    >
                    >
                  • Ron Vutpakdi
                    ... guidelines ... never ... As a general rule, yes, the concepts and guidelines need to be consistent and fit together logically as much as possible. But,
                    Message 9 of 10 , Oct 7, 2004
                    • 0 Attachment
                      --- In agile-usability@yahoogroups.com, "Michael Mahemoff (Mailing
                      Lists)" <michaellists@m...> wrote:
                      > This is an interesting point about tools - I have found there are
                      > several steps a platform's facilitator can take to promote UI
                      guidelines
                      > flourish across the community. I did some research on style guides a
                      > while back, and a few success factors were:
                      >
                      > * The concepts. Most importantly, the concepts have to be logical and
                      > fit together cohesively. No good having one guideline suggest "3D
                      never"
                      > and another suggest "raise/lower buttons".

                      As a general rule, yes, the concepts and guidelines need to be
                      consistent and fit together logically as much as possible. But, it's
                      really hard to come up with general, practical guidelines which will
                      work together logically in every situation because a considerable
                      portion of good design (in any discipline/domain) comes down to
                      analyzing the context, goals, and situation and knowing when to follow
                      the guidelines (which is what should happen most of the time) and when
                      to violate the guidelines. In other words, "it depends" gets used
                      quite a bit.

                      Ron
                    • Michael Mahemoff
                      ... Right, because conventional windows platforms let you work in any discipline/domain you care to name. Where it gets more interesting is in specialised
                      Message 10 of 10 , Oct 9, 2004
                      • 0 Attachment
                        Ron Vutpakdi wrote:

                        >
                        > --- In agile-usability@yahoogroups.com, "Michael Mahemoff (Mailing
                        > Lists)" <michaellists@m...> wrote:
                        >
                        >>This is an interesting point about tools - I have found there are
                        >>several steps a platform's facilitator can take to promote UI
                        >
                        > guidelines
                        >
                        >>flourish across the community. I did some research on style guides a
                        >>while back, and a few success factors were:
                        >>
                        >> * The concepts. Most importantly, the concepts have to be logical and
                        >>fit together cohesively. No good having one guideline suggest "3D
                        >
                        > never"
                        >
                        >>and another suggest "raise/lower buttons".
                        >
                        >
                        > As a general rule, yes, the concepts and guidelines need to be
                        > consistent and fit together logically as much as possible. But, it's
                        > really hard to come up with general, practical guidelines which will
                        > work together logically in every situation because a considerable
                        > portion of good design (in any discipline/domain) comes down to
                        > analyzing the context, goals, and situation and knowing when to follow
                        > the guidelines (which is what should happen most of the time) and when
                        > to violate the guidelines. In other words, "it depends" gets used
                        > quite a bit.
                        >

                        Right, because conventional windows platforms let you work in any
                        discipline/domain you care to name.

                        Where it gets more interesting is in specialised devices. For instance,
                        PDAs in the mid-1990s. The hardware was there, but there were many
                        different views on how to write a PDA application. When PalmOS and WinCE
                        came along (and later, Pocket PC), they each took very different
                        directions. Both were internally consistent and both imposed strong
                        constraints on developers. So many issues that previously "depended" had
                        already been decided upon, encapsulated in the principles of the
                        respective platforms.

                        BTW It's interesting to note that these are examples of platforms where
                        tooling and flagship applications (e.g. Palm's MemoPad, Address, etc.)
                        played a superior role to style guide documentation.
                      Your message has been successfully submitted and would be delivered to recipients shortly.