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

designer owns presentation layer?

Expand Messages
  • Jeff Patton
    Over the last sever years I ve worked on systems where the UI designer has ended up owning the presentation layer. By that I mean the application was
    Message 1 of 16 , Aug 30, 2004

      Over the last sever years I’ve worked on systems where the UI designer has ended up owning the presentation layer.  By that I mean the application was technically designed in such a way that the functionality was contained in objects that could be used by a UI designer who maintained things like Java Server Pages or in one project I participated in XSLT files.  In software my teams have built in the past using a Java Swing Client, we used an XML markup language to lay out Swing panels, tables, and other components.  UI designers could take responsibility for those, and that design could be changed independently of the business logic.

       

      The thread on UI guidelines and how hard it is to get developers to comply with them made me think about this.  Thinking back to the most successful projects I’ve participated on, UI-wise, the software was built in such a way that the people best at designing UI could be the ones responsible.  If I heard Thyra Rauch correctly in an earlier post, she’s an example of a designer that actually codes the UI.  Does anyone else have examples of this working?  Or does anyone have opinions about this as a technique or strategy?

       

      Thanks,

       

      -Jeff

       

      ---------------------

      Jeff Patton

      www.abstractics.com/papers

      OOPSLA Tutorial: www.oopsla.org/2004/ShowEvent.do?id=105

       

      "Computers are useless. They can only give you answers."

      -- PABLO PICASSO

       

    • Thyra Rauch
      Jeff, Just to make sure the record is straight.......I can code UI, in some very limited languages, if needed, and have done so very occasionally. I also
      Message 2 of 16 , Aug 30, 2004

        Jeff,
        Just to make sure the record is straight.......I "can" code UI, in some very limited languages, if needed, and have done so very occasionally.  I also "can" code the prototype/working spec if needed so it "looks" just like the actual GUI.  Most of the time, my time is better spent doing other things, as I usually have the privilege of working, glued at the hip,  with some outstanding GUI programmers.  And, in this case, we are still separating the coding of the UI from the coding of the internals, which has worked extremely well for us as we can work ahead independently, and then sync with the team (usually working about 1 iteration ahead).
        Thyra

        trauch@...
        Customer Research Architect
        DB2 Information Integration and Search
        Phone:  408-463-2465



        "Jeff Patton" <jpatton@...>

        08/30/2004 03:58 PM

        Please respond to
        agile-usability

        To
        <agile-usability@yahoogroups.com>
        cc
        Subject
        [agile-usability] designer owns presentation layer?





        Over the last sever years I’ve worked on systems where the UI designer has ended up owning the presentation layer.  By that I mean the application was technically designed in such a way that the functionality was contained in objects that could be used by a UI designer who maintained things like Java Server Pages or in one project I participated in XSLT files.  In software my teams have built in the past using a Java Swing Client, we used an XML markup language to lay out Swing panels, tables, and other components.  UI designers could take responsibility for those, and that design could be changed independently of the business logic.
         
        The thread on UI guidelines and how hard it is to get developers to comply with them made me think about this.  Thinking back to the most successful projects I’ve participated on, UI-wise, the software was built in such a way that the people best at designing UI could be the ones responsible.  If I heard Thyra Rauch correctly in an earlier post, she’s an example of a designer that actually codes the UI.  Does anyone else have examples of this working?  Or does anyone have opinions about this as a technique or strategy?
         
        Thanks,
         
        -Jeff
         
        ---------------------
        Jeff Patton
        www.abstractics.com/papers
        OOPSLA Tutorial: www.oopsla.org/2004/ShowEvent.do?id=105
         
        "Computers are useless. They can only give you answers."
        -- PABLO PICASSO
         

        Yahoo! Groups Sponsor
        ADVERTISEMENT
        click here




        Yahoo! Groups Links
      • Gary
        Hi, Bringing both of these posts together, I finished (a few months ago) coding the UI chunks in XSLT that the developers then inserted into page shells and
        Message 3 of 16 , Aug 30, 2004
          Hi,

          Bringing both of these posts together, I finished (a few months ago)
          coding the UI chunks in XSLT that the developers then inserted into page
          shells and blended with some widgets that they coded but the UI team
          spec'ed. Similarly, in one of my less well paying jobs I've coded the
          complete UI (web) and continue to maintain it. what is the best use of
          my time? The only answer I know is doing whatever gets the project
          completed the best and at lowest cost. I did the XSL's because none of
          the developers knew the language well enough and management decided it
          was more cost effective for me to do it (I had no background in it and
          they knew it).

          So in some cases I've truly done the whole thing from the user research
          thru delivering the product.

          gary

          Thyra Rauch wrote:

          >
          > Jeff,
          > Just to make sure the record is straight.......I "can" code UI, in some
          > very limited languages, if needed, and have done so very occasionally.
          > I also "can" code the prototype/working spec if needed so it "looks"
          > just like the actual GUI. Most of the time, my time is better spent
          > doing other things, as I usually have the privilege of working, glued at
          > the hip, with some outstanding GUI programmers. And, in this case, we
          > are still separating the coding of the UI from the coding of the
          > internals, which has worked extremely well for us as we can work ahead
          > independently, and then sync with the team (usually working about 1
          > iteration ahead).
          > Thyra
          >
          > trauch@...
          > Customer Research Architect
          > DB2 Information Integration and Search
          > Phone: 408-463-2465
          >
          >
          >
          > *"Jeff Patton" <jpatton@...>*
          >
          > 08/30/2004 03:58 PM
          > Please respond to
          > agile-usability
          >
          >
          >
          > To
          > <agile-usability@yahoogroups.com>
          > cc
          >
          > Subject
          > [agile-usability] designer owns presentation layer?
          >
          >
          >
          >
          >
          >
          >
          >
          > Over the last sever years I’ve worked on systems where the UI designer
          > has ended up owning the presentation layer. By that I mean the
          > application was technically designed in such a way that the
          > functionality was contained in objects that could be used by a UI
          > designer who maintained things like Java Server Pages or in one project
          > I participated in XSLT files. In software my teams have built in the
          > past using a Java Swing Client, we used an XML markup language to lay
          > out Swing panels, tables, and other components. UI designers could take
          > responsibility for those, and that design could be changed independently
          > of the business logic.
          >
          > The thread on UI guidelines and how hard it is to get developers to
          > comply with them made me think about this. Thinking back to the most
          > successful projects I’ve participated on, UI-wise, the software was
          > built in such a way that the people best at designing UI could be the
          > ones responsible. If I heard Thyra Rauch correctly in an earlier post,
          > she’s an example of a designer that actually codes the UI. Does anyone
          > else have examples of this working? Or does anyone have opinions about
          > this as a technique or strategy?
          >
          > Thanks,
          >
          > -Jeff
          >
          > ---------------------
          > Jeff Patton
          > www.abstractics.com/papers
          > OOPSLA Tutorial: _www.oopsla.org/2004/ShowEvent.do?id=105_
          > <http://www.oopsla.org/2004/ShowEvent.do?id=105>
          >
          > "Computers are useless. They can only give you answers."
          > -- PABLO PICASSO
        • Gary
          I guess I should also say that I ve worked with some UI folks who were proud of not knowing how to code and steadfastly refused to investigate the limitations
          Message 4 of 16 , Aug 30, 2004
            I guess I should also say that I've worked with some UI folks who were
            proud of not knowing how to code and steadfastly refused to investigate
            the limitations inherent in choosing a UI platform.

            different strokes...

            gary


            Gary wrote:

            > Hi,
            >
            > Bringing both of these posts together, I finished (a few months ago)
            > coding the UI chunks in XSLT that the developers then inserted into page
            > shells and blended with some widgets that they coded but the UI team
            > spec'ed. Similarly, in one of my less well paying jobs I've coded the
            > complete UI (web) and continue to maintain it. what is the best use of
            > my time? The only answer I know is doing whatever gets the project
            > completed the best and at lowest cost. I did the XSL's because none of
            > the developers knew the language well enough and management decided it
            > was more cost effective for me to do it (I had no background in it and
            > they knew it).
            >
            > So in some cases I've truly done the whole thing from the user research
            > thru delivering the product.
            >
            > gary
            >
            > Thyra Rauch wrote:
            >
            > >
            > > Jeff,
            > > Just to make sure the record is straight.......I "can" code UI, in some
            > > very limited languages, if needed, and have done so very occasionally.
            > > I also "can" code the prototype/working spec if needed so it "looks"
            > > just like the actual GUI. Most of the time, my time is better spent
            > > doing other things, as I usually have the privilege of working, glued at
            > > the hip, with some outstanding GUI programmers. And, in this case, we
            > > are still separating the coding of the UI from the coding of the
            > > internals, which has worked extremely well for us as we can work ahead
            > > independently, and then sync with the team (usually working about 1
            > > iteration ahead).
            > > Thyra
            > >
            > > trauch@...
            > > Customer Research Architect
            > > DB2 Information Integration and Search
            > > Phone: 408-463-2465
            > >
            > >
            > >
            > > *"Jeff Patton" <jpatton@...>*
            > >
            > > 08/30/2004 03:58 PM
            > > Please respond to
            > > agile-usability
            > >
            > >
            > >
            > > To
            > > <agile-usability@yahoogroups.com>
            > > cc
            > >
            > > Subject
            > > [agile-usability] designer owns presentation layer?
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > > Over the last sever years I’ve worked on systems where the UI designer
            > > has ended up owning the presentation layer. By that I mean the
            > > application was technically designed in such a way that the
            > > functionality was contained in objects that could be used by a UI
            > > designer who maintained things like Java Server Pages or in one project
            > > I participated in XSLT files. In software my teams have built in the
            > > past using a Java Swing Client, we used an XML markup language to lay
            > > out Swing panels, tables, and other components. UI designers could take
            > > responsibility for those, and that design could be changed independently
            > > of the business logic.
            > >
            > > The thread on UI guidelines and how hard it is to get developers to
            > > comply with them made me think about this. Thinking back to the most
            > > successful projects I’ve participated on, UI-wise, the software was
            > > built in such a way that the people best at designing UI could be the
            > > ones responsible. If I heard Thyra Rauch correctly in an earlier post,
            > > she’s an example of a designer that actually codes the UI. Does anyone
            > > else have examples of this working? Or does anyone have opinions about
            > > this as a technique or strategy?
            > >
            > > Thanks,
            > >
            > > -Jeff
            > >
            > > ---------------------
            > > Jeff Patton
            > > www.abstractics.com/papers
            > > OOPSLA Tutorial: _www.oopsla.org/2004/ShowEvent.do?id=105_
            > > <http://www.oopsla.org/2004/ShowEvent.do?id=105>
            > >
            > > "Computers are useless. They can only give you answers."
            > > -- PABLO PICASSO
          • Petteri Hiisilä
            ... It s a dangerous conflict of interest. If you re responsible for implementing the design, you will - consciously or unconsciously - be making design
            Message 5 of 16 , Aug 31, 2004
              Jeff Patton wrote:

              > <>The thread on UI guidelines and how hard it is to get developers to
              > comply with them made me think about this. Thinking back to the most
              > successful projects I’ve participated on, UI-wise, the software was
              > built in such a way that the people best at designing UI could be the
              > ones responsible. If I heard Thyra Rauch correctly in an earlier post,
              > she’s an example of a designer that actually codes the UI. Does anyone
              > else have examples of this working? Or does anyone have opinions about
              > this as a technique or strategy?

              It's a dangerous conflict of interest. If you're responsible for
              implementing the design, you will - consciously or unconsciously - be
              making design decisions based partly on how hard it will be to actually
              code the thing.

              Worrying too much about implementation complexity (technical or software
              design) will compromise your ability to do /superior/ human design.
              That's lesson one. I wrote about it a couple of days ago. Lots of people
              have written about it. It should be accepted as a fact. Being your own
              judge has a lot of problems.

              Saying this isn't the same as saying that if you always code your own
              UI's, they're always going to be crap, no matter what. I don't mean
              that. Sure you still /can/ do good job, but you'll need a big brain and
              a lot of honesty.

              If you for any reason - and it'd better be a good one - have to code
              your own UI, try hard to forget the implementation details at first.
              Just concentrate on what the cockpit should be like, if almost
              everything was possible. Make sure that all the important human goals
              are satisfied. /Then downgrade that to something that you can implement
              in time, but look carefully where you cut. It might be the thumb./

              Making things easy for people is hard.

              - Petteri

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

              "I know what I believe. I will continue to believe
              what I believe and what I believe - I believe what
              I believe is right."

              - George W. Bush
            • hj
              ... Alternatively, you may be wasting your time coming up with a design that is impossible to implement. My company develops products for paying customers who
              Message 6 of 16 , Aug 31, 2004
                > -----Original Message-----
                > From: Petteri Hiisilä [mailto:petteri.hiisila@...]
                >
                > Worrying too much about implementation complexity (technical
                > or software
                > design) will compromise your ability to do /superior/ human design.

                Alternatively, you may be wasting your time coming up with a design that is
                impossible to implement.

                My company develops products for paying customers who want real solutions
                ... I have to come up with designs that are user-focused, fit-for-purpose
                and that also have a chance of being developed given the constraints of the
                available GUI widget libraries, the implementation resources, the time
                available etc.

                Ok, so I really push the GUI programmers a lot of the time in design terms,
                but I know when and how I am pushing them as I understand their
                implementation constraints. Sometimes they really can't do it, so in those
                cases I am also usually pre-prepared with an easier, alternative design
                which, while not providing an optimal user experience, is pretty close.

                Understanding the implementation world also allows me to know if a
                programmer is being 'economical with the truth' when they say something is
                impossible to implement, and allows me the chance to sometimes provide them
                with a viable solution in these cases. Luckily, this rarely happens as the
                implementers I work with are very good.

                So I believe there needs to be a balance .. between the desire for optimal
                user experience and the down-to-earth practicalities of implementing it.
                Ignoring one or the other leads to problems, in my opinion.

                > Making things easy for people is hard.

                Absolutely.

                - h
              • Petteri Hiisilä
                ... (A competent) interaction designer wouldn t do that... That would be considered a serious failure from their side. They have to know technical constraints
                Message 7 of 16 , Aug 31, 2004

                  > -----Original Message-----
                  > From: Petteri Hiisilä [mailto:petteri.hiisila@...]
                  >
                  > Worrying too much about implementation complexity (technical
                  > or software
                  > design) will compromise your ability to do /superior/ human design.

                  Alternatively, you may be wasting your time coming up with a design that is
                  impossible to implement.

                  (A competent) interaction designer wouldn't do that...  That would be considered a serious failure from their side. They have to know technical constraints and know when they're asking a lot. If they do so, they do it for a reason. That's why developers can become good at it, if they have the right attitude and training. ID's stress ~75 % or more on human design, ~25 % or less on technical design. Not literally, but that's the attitude.

                  Sounds like you have it.

                  The optimal solution is as simple as possible, but no simpler.

                  Of course, this is all theory. In practice it's always quite complicated.
                  Ok, so I really push the GUI programmers a lot of the time in design terms,
                  but I know when and how I am pushing them as I understand their
                  implementation constraints. Sometimes they really can't do it, so in those
                  cases I am also usually pre-prepared with an easier, alternative design
                  which, while not providing an optimal user experience, is pretty close.
                  Exactly! That's what I mean by "downgrading" a design. As you said, it's best to think it in advance.
                  So I believe there needs to be a balance .. between the desire for optimal
                  user experience and the down-to-earth practicalities of implementing it.
                  Ignoring one or the other leads to problems, in my opinion.
                  Sure. It's like arguing which is more important: breathing or eating? The same rule applies with the management vs. human design. vs. technical design too. It was discussed in a different thread. Lose one, lose all.

                   - Petteri

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

                  "I know what I believe. I will continue to believe
                  what I believe and what I believe - I believe what
                  I believe is right."

                  - George W. Bush

                • Brian O'Byrne
                  ... We ve used exactly the same techniques with good results. A number of small web-based projects I worked on a few years ago followed a pattern: The
                  Message 8 of 16 , Aug 31, 2004
                    On Monday 30 August 2004 23:58, Jeff Patton wrote:
                    > Over the last sever years I've worked on systems where the UI
                    > designer has ended up owning the presentation layer. By that I
                    > mean the application was technically designed in such a way that
                    > the functionality was contained in objects that could be used by a
                    > UI designer who maintained things like Java Server Pages or in one
                    > project I participated in XSLT files. In software my teams have
                    > built in the past using a Java Swing Client, we used an XML markup
                    > language to lay out Swing panels, tables, and other components. UI
                    > designers could take responsibility for those, and that design
                    > could be changed independently of the business logic.

                    We've used exactly the same techniques with good results.
                    A number of small web-based projects I worked on a few years ago
                    followed a pattern:
                    The interaction designer would specify the information that should be
                    presented on each page, along with the events/interactions available
                    off the page. The Java developers would produce XML that contained
                    the required data. An independent team of XSLT & graphic designers
                    would use the data to render the screens.
                    The communication to the UI team was very simple: a set of DTDs
                    describing the XML.

                    As a testament to the success of the method I went back to one of
                    those sites three years after the initial launch to help a rebranding
                    effort. The appearance of the site was completely changed to specs
                    presented by a completely new graphic design and marketing team.
                    The only code changed was the XSLT.

                    > The thread on UI guidelines and how hard it is to get developers to
                    > comply with them made me think about this. Thinking back to the
                    > most successful projects I've participated on, UI-wise, the
                    > software was built in such a way that the people best at designing
                    > UI could be the ones responsible. If I heard Thyra Rauch correctly
                    > in an earlier post, she's an example of a designer that actually
                    > codes the UI. Does anyone else have examples of this working? Or
                    > does anyone have opinions about this as a technique or strategy?

                    Without a doubt the best results I have seen came from a team of
                    programmers that embraced an interaction design technique, supported
                    by mentors with interaction design experience and a framework that
                    allowed them work independently of the problem domain team.

                    This team started from the very difficult position of being seen as a
                    'necessary evil'. The company was in the business of selling
                    solutions to the financial services industry, and valued the
                    engineering team and domain experts. The UI development was seen as a
                    necessary cost rather than a source of value.

                    The UI proved to be the weak link in a number of projects, in one case
                    turning what should have been an unqualified success into a death
                    march: everyone agreed all the features required were deployed but it
                    just didn't work and no-one knew how to fix it.

                    In desperation that team turned to a formal interaction design
                    technique to try and fix the UI. A few people taught themselves the
                    basics, brought in a framework and managed to pull off a coup. After
                    pulling that project back from the brink they infected other projects
                    with an enthusiasm for the new technique.

                    Now that technique and framework is fully supported by the management
                    and the UI is not a weak link.

                    The drive for a better interaction design is coming from the
                    programmers. I've seen team members look at a design they have been
                    asked to implement, decide it could be done better and go back to the
                    domain experts to suggest a change. Often they are right and the
                    domain expert agrees to the design change. The framework helps
                    minimise the cost of the change so the project manager doesn't
                    object. Everyone wins.

                    Brian.
                    --
                    Brian O'Byrne, Statesoft Ltd.
                    Tel: +353 1 4498 151, +353 86 240 4719
                    http://www.statesoft.ie/
                  • Ron Vutpakdi
                    ... comply ... successful ... such a way ... If I ... of this ... I think that it s possible, but difficult and perhaps a little dangerous. Depending on the
                    Message 9 of 16 , Aug 31, 2004
                      --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...>
                      wrote:
                      > The thread on UI guidelines and how hard it is to get developers to
                      comply
                      > with them made me think about this. Thinking back to the most
                      successful
                      > projects I've participated on, UI-wise, the software was built in
                      such a way
                      > that the people best at designing UI could be the ones responsible.
                      If I
                      > heard Thyra Rauch correctly in an earlier post, she's an example of a
                      > designer that actually codes the UI. Does anyone else have examples
                      of this
                      > working? Or does anyone have opinions about this as a technique or
                      > strategy?

                      I think that it's possible, but difficult and perhaps a little dangerous.

                      Depending on the toolset, having the interaction designers responsible
                      for the actual implementation may mean that the interaction designers
                      have to be good interaction designers *AND* good software engineers.
                      As a general rule, most development teams that I've worked with
                      probably don't want someone who isn't good at structuring and writing
                      the code (from an internal perspective) to write the code.

                      Since I have a background in software development, I can design and
                      write good code from an internal standpoint. Even then, I would be
                      less effective than a good team of an interaction designer and a
                      developer since my attention and time would be divided.

                      On the other hand, this idea would work if you could have a tool that,
                      for example, could take something like a wireframe and then render
                      that in good code (with some interactivity built in). There are some
                      pretty decent GUI builders out there (for Java Swing), but I haven't
                      found one yet which hides enough of the Java and internal class design
                      aspects to be something that I'd recommend for non-developers.

                      Ron
                    • Petteri Hiisilä
                      Ron Vutpakdi wrote ... I would need that too... Just something that can be used to show static screens based on what widget I push. Just
                      Message 10 of 16 , Aug 31, 2004
                        Ron Vutpakdi <vutpakdi@...> wrote

                        >
                        > On the other hand, this idea would work if you could have a tool that,
                        > for example, could take something like a wireframe and then render
                        > that in good code (with some interactivity built in). There are some
                        > pretty decent GUI builders out there (for Java Swing), but I haven't
                        > found one yet which hides enough of the Java and internal class design
                        > aspects to be something that I'd recommend for non-developers.
                        >
                        I would need that too... Just something that can be used to show static
                        screens based on what widget I push. Just basic scripting, no real
                        coding. Visual Basic or Java Swing is way too complex to support my
                        goals. It will just get on my way with all the details.

                        I would use that software to demonstrate my design to stakeholders and
                        developers. It would be an interactive and powerful way to show what the
                        application might be like, when it's done. It should allow very quick,
                        live editing on-site. Different versions of the same design etc.

                        It should also have a capability to record interviews (written and oral,
                        perhaps video too), model and express Personas and their goals. If I
                        hover the mouse over a goal, it would visually show the parts of
                        interviews, variables and notes, that have lead me to write down a
                        certain goal. I would use that to defend my Personas (and the design) in
                        meetings.

                        Wireframe model and even the widgets could be tracked back to functional
                        requirements, screnarios and Personas also. Again, to market, defend and
                        demonstrate the design.

                        I could script some key scenarios with explanation bubbles. That would
                        support developers when they're implementing some more complex
                        interaction. It could even enable a creation of the Form & Behavior
                        Spec, and publish it out as a hypertext version.

                        This should be included in Rational, for instance. Just like Dave
                        (Cronin) wrote.
                        http://www.cooper.com/content/insights/newsletters/2003_07/RUP_&_GDD.asp

                        Anybody wants to develop something like that? I could write you a spec :)

                        - Petteri

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

                        "I know what I believe. I will continue to believe
                        what I believe and what I believe - I believe what
                        I believe is right."

                        - George W. Bush
                      • Desilets, Alain
                        Over the last sever years I ve worked on systems where the UI designer has ended up owning the presentation layer. By that I mean the application was
                        Message 11 of 16 , Aug 31, 2004
                          Message

                          Over the last sever years I've worked on systems where the UI designer has ended up owning the presentation layer.  By that I mean the application was technically designed in such a way that the functionality was contained in objects that could be used by a UI designer who maintained things like Java Server Pages or in one project I participated in XSLT files.  In software my teams have built in the past using a Java Swing Client, we used an XML markup language to lay out Swing panels, tables, and other components.  UI designers could take responsibility for those, and that design could be changed independently of the business logic.

                           

                          The thread on UI guidelines and how hard it is to get developers to comply with them made me think about this.  Thinking back to the most successful projects I've participated on, UI-wise, the software was built in such a way that the people best at designing UI could be the ones responsible.  If I heard Thyra Rauch correctly in an earlier post, she's an example of a designer that actually codes the UI.  Does anyone else have examples of this working?  Or does anyone have opinions about this as a technique or strategy?

                           

                          Thanks, 

                           

                          -- Alain:

                          I used to do all my UI development with easy to use high level tools like Visual Basic. That was fine as long as I was just building prototypes. As soon as I got into developping UIs for production systems that had to be maintained, I found I had to write much more sophisticated code.

                           

                          In particular, if you want your UI to be regression testable, you have to use something like a ModelViewController approach, or a more simple HumbleDialogBox approach.

                           

                          I guess you could have the UI designer implement the View, and a more seasonned programmer develop the Model and Controller, but there usually are lots of dependencies between them so I suspect that process would not work too well. Probably best to teach the UI designer how to write UIs test-first.

                           

                          -----

                        • William Pietri
                          ... On a current project, the project manager is an expert web UI designer. He maintains the CSS files nearly exclusively, and usually produces HTML mockups
                          Message 12 of 16 , Aug 31, 2004
                            On Mon, 2004-08-30 at 15:58, Jeff Patton wrote:
                            > The thread on UI guidelines and how hard it is to get developers to
                            > comply with them made me think about this. Thinking back to the most
                            > successful projects I’ve participated on, UI-wise, the software was
                            > built in such a way that the people best at designing UI could be the
                            > ones responsible. If I heard Thyra Rauch correctly in an earlier
                            > post, she’s an example of a designer that actually codes the UI. Does
                            > anyone else have examples of this working? Or does anyone have
                            > opinions about this as a technique or strategy?

                            On a current project, the project manager is an expert web UI designer.
                            He maintains the CSS files nearly exclusively, and usually produces HTML
                            mockups for the developers, who tear them into OO-shaped pieces and
                            implement them.

                            This has worked quite well. At first the designer was nervous giving up
                            control of the HTML, but any changes he want happen quickly. Also, the
                            developers, who are always looking for oppotunities for reuse, have made
                            the HTML more consistent across sections of the application. The
                            breadcrumb trails, for example, are perfectly consistent because they're
                            all rendered by the same object.

                            Eventually, we do expect some sort of framework to come out of this, so
                            that anybody, designer or developer, can declare things in templates or
                            configuration files. But the time for that hasn't yet come.

                            William
                          • William Pietri
                            ... Oh, and there s certainly another possibility. Back in Ye Olden Dayes, the computer company NeXT had a tool called Interface Builder. It was a great
                            Message 13 of 16 , Aug 31, 2004
                              On Mon, 2004-08-30 at 15:58, Jeff Patton wrote:
                              > The thread on UI guidelines and how hard it is to get developers to
                              > comply with them made me think about this. Thinking back to the most
                              > successful projects I’ve participated on, UI-wise, the software was
                              > built in such a way that the people best at designing UI could be the
                              > ones responsible. If I heard Thyra Rauch correctly in an earlier
                              > post, she’s an example of a designer that actually codes the UI.


                              Oh, and there's certainly another possibility. Back in Ye Olden Dayes,
                              the computer company NeXT had a tool called Interface Builder. It was a
                              great graphical tool for building GUIs and then connecting them to the
                              underlying code. No code generation was involved; it output binary files
                              that were interpreted by the NeXT runtime. It was so cleanly done that
                              you could crack open an existing commercial program, edit the interface
                              files, and put everything back together, fixing UI annoyances in
                              programs where you didn't have the source code.

                              At the time, many Chicago banks and financial companies used the NeXT
                              platform to build in-house tools for financial traders. A few of them
                              had evolved a working style such that developers would build the
                              back-end components and somebody with a lot of domain knowledge -- maybe
                              a business analyst acting as product manager, maybe the traders
                              themselves -- would use IB to put together the interface. When no
                              interface components on the standard palates would suffice, interface
                              designers would collaborate with programmers. But generally, UI
                              designers didn't have to write any code.

                              I've never seen anything close to like this for Java or .NET,
                              unfortunately.

                              William
                            • Andrew Lawrence
                              ... Why does this happen so often? I have been part of the necessary evil team a few times now - each time resulting in being able to pull off a coup -- but
                              Message 14 of 16 , Aug 31, 2004
                                --- In agile-usability@yahoogroups.com, Brian O'Byrne <bobyrne@s...>
                                wrote:
                                > Without a doubt the best results I have seen came from a team of
                                > programmers that embraced an interaction design technique,
                                > supported by mentors with interaction design experience and a
                                > framework that allowed them work independently of the problem
                                > domain team.
                                >
                                > This team started from the very difficult position of being seen
                                > as a 'necessary evil'. The company was in the business of selling
                                > solutions to the financial services industry, and valued the
                                > engineering team and domain experts. The UI development was seen
                                > as a necessary cost rather than a source of value.
                                >
                                > The UI proved to be the weak link in a number of projects, in
                                > one case turning what should have been an unqualified success
                                > into a death march: everyone agreed all the features required
                                > were deployed but it just didn't work and no-one knew how to fix it.
                                >
                                > In desperation that team turned to a formal interaction design
                                > technique to try and fix the UI. A few people taught themselves the
                                > basics, brought in a framework and managed to pull off a coup.
                                > After pulling that project back from the brink they infected other
                                > projects with an enthusiasm for the new technique.

                                Why does this happen so often? I have been part of the "necessary
                                evil" team a few times now - each time resulting in being able to
                                pull off a coup -- but in my case, the success of the resulting
                                software is soon overshadowed by the coup that resulted. This
                                results in the shunning of the software, instead of the adoptation
                                of it in general, since the software is perceived as being too
                                reliant upon the team that built it, and "non-standard".

                                As a separate note, I agree with your observation that the best
                                results I have seen have come from a team of programmers that
                                embraced an interaction design technique, supported by mentors
                                with interaction design experience and a framework that allowed
                                them work independently of the problem domain team. I usually
                                gave the idea of a "framework" and independance of the ID team
                                a name... the separation of "application" vs. "content". I
                                mentioned it further in another thread.
                                http://groups.yahoo.com/group/agile-usability/message/441

                                IMHO, the team that is able to keep this separation of what
                                is "application" (i.e. framework) and what is "content" in
                                the software usually comes out ahead.

                                -- Andrew Lawrence
                                andrew9990@...
                              • Erik Hanson
                                ... I like this approach. I have worked on a few webapp projects where we spent a lot of time implementing or integrating template systems. The reward for all
                                Message 15 of 16 , Sep 6, 2004
                                  On Aug 31, 2004, at 9:20 AM, William Pietri wrote:
                                  > On a current project, the project manager is an expert web UI designer.
                                  > He maintains the CSS files nearly exclusively, and usually produces
                                  > HTML
                                  > mockups for the developers, who tear them into OO-shaped pieces and
                                  > implement them.
                                  >
                                  > This has worked quite well. At first the designer was nervous giving up
                                  > control of the HTML, but any changes he want happen quickly. Also, the
                                  > developers, who are always looking for oppotunities for reuse, have
                                  > made
                                  > the HTML more consistent across sections of the application. The
                                  > breadcrumb trails, for example, are perfectly consistent because
                                  > they're
                                  > all rendered by the same object.

                                  I like this approach.

                                  I have worked on a few webapp projects where we spent a lot of time
                                  implementing or integrating template systems. The reward for all this
                                  up-front effort was that the UI folks could change the UI whenever they
                                  pleased. However, most of the UI changes usually required code changes
                                  as well, and those code changes were harder because we had to modify a
                                  lot of hard-to-test, hard-to-reuse template stuff.



                                  > Eventually, we do expect some sort of framework to come out of this, so
                                  > that anybody, designer or developer, can declare things in templates or
                                  > configuration files. But the time for that hasn't yet come.

                                  I'm going to guess that the time for that will never come.


                                  Erik
                                • Erik Hanson
                                  ... Back in Ye Oldener Dayes, Apple s ResEdit did something similar. It s not surprising that NeXT used a similar approach, as I m guessing that Steve Jobs
                                  Message 16 of 16 , Sep 6, 2004
                                    On Aug 31, 2004, at 9:34 AM, William Pietri wrote:
                                    > Oh, and there's certainly another possibility. Back in Ye Olden Dayes,
                                    > the computer company NeXT had a tool called Interface Builder. It was a
                                    > great graphical tool for building GUIs and then connecting them to the
                                    > underlying code. No code generation was involved; it output binary
                                    > files
                                    > that were interpreted by the NeXT runtime. It was so cleanly done that
                                    > you could crack open an existing commercial program, edit the interface
                                    > files, and put everything back together, fixing UI annoyances in
                                    > programs where you didn't have the source code.

                                    Back in Ye Oldener Dayes, Apple's ResEdit did something similar. It's
                                    not surprising that NeXT used a similar approach, as I'm guessing that
                                    Steve Jobs took a bunch of Apple folks when he founded NeXT. Apple of
                                    course owns NeXT now, and Interface Builder is now at the heart of Mac
                                    application development.


                                    Erik
                                  Your message has been successfully submitted and would be delivered to recipients shortly.