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

(Possibly OT) Inline Editing vs. Separate Page

Expand Messages
  • Dave Rooney
    Hi folks, I m not sure if this is a proper forum for this question, but I m sure someone will tell me so if it isn t. ;) During an iteration planning meeting,
    Message 1 of 27 , Jan 6, 2009
    • 0 Attachment
      Hi folks,

      I'm not sure if this is a proper forum for this question, but I'm sure
      someone will tell me so if it isn't. ;)

      During an iteration planning meeting, there was some debate about the UI
      for a feature. The users currently have an Excel spreadsheet on
      steroids. At the last iteration demo, one comment was made that the new
      web application's UI has a separate page for editing some data that is
      currently edited "in place" in the spreadsheet. The developers are
      being told that there will definitely be some pushback to using a
      separate page.

      My experience going back 20 years is that in place editing of list-based
      data is a PITA and prone to defects. However, that's from a developer's
      persepective. What is the usability world's view on this?

      Thanks in advance!

      --

      Dave Rooney
      Mayford Technologies
      "Helping you become AGILE... to SURVIVE and THRIVE!"
      http://www.mayford.ca
      http://practicalagility.blogspot.com
      Twitter: daverooneyca
    • Mike Dwyer
      Dave While I want to agree with you I am not sure what PITA stands for, other than what I sometimes wrap tuna salad in. I find the use of an excel spreadsheet
      Message 2 of 27 , Jan 6, 2009
      • 0 Attachment

        Dave

        While I want to agree with you I am not sure what PITA stands for, other than what I sometimes wrap tuna salad in.

         

        I find the use of an excel spreadsheet to be of interest is well.  Can I assume their card reader is waiting for parts?

         

        Mike Dwyer
        Principal, Agile Coach

        BigVisible Solutions
        url:    http://www.bigvisible.com

        cell:   (978) 376-4422

        email: mdwyer@...

         

         

        From: Dave Rooney [mailto:dave.rooney@...]
        Sent: Tuesday, January 06, 2009 11:11 AM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] (Possibly OT) Inline Editing vs. Separate Page

         

        Hi folks,

        I'm not sure if this is a proper forum for this question, but I'm sure
        someone will tell me so if it isn't. ;)

        During an iteration planning meeting, there was some debate about the UI
        for a feature. The users currently have an Excel spreadsheet on
        steroids. At the last iteration demo, one comment was made that the new
        web application's UI has a separate page for editing some data that is
        currently edited "in place" in the spreadsheet. The developers are
        being told that there will definitely be some pushback to using a
        separate page.

        My experience going back 20 years is that in place editing of list-based
        data is a PITA and prone to defects. However, that's from a developer's
        persepective. What is the usability world's view on this?

        Thanks in advance!

        --

        Dave Rooney
        Mayford Technologies
        "Helping you become AGILE... to SURVIVE and THRIVE!"
        http://www.mayford.ca
        http://practicalagility.blogspot.com
        Twitter: daverooneyca

      • William Pietri
        Dave, I think this is quite a good place for your query. I think one of the most interesting issues, and certainly one of the most persistent, is how to manage
        Message 3 of 27 , Jan 6, 2009
        • 0 Attachment
          Dave, I think this is quite a good place for your query. I think one of the most interesting issues, and certainly one of the most persistent, is how to manage UI change in agile contexts. I'd love to see more discussion of that.

          A couple of comments to Mike:

          Mike Dwyer wrote:

          Dave

          While I want to agree with you I am not sure what PITA stands for, other than what I sometimes wrap tuna salad in.


          http://www.acronymfinder.com/PITA.html

          I find the use of an excel spreadsheet to be of interest is well.  Can I assume their card reader is waiting for parts?


          Although I understand what you mean, this is surprisingly common. Excel is one of those rare things in which non-developer domain experts can actually build quite a bit of functionality on their own. Then a complex spreadsheet may get adopted by developers for further extension or integration with other software. Perhaps that's through uploading the spreadsheets, generating them, or making calls from a spreadsheet to other systems.

          I once worked for financial traders, an environment in which developers sometimes outnumbered users. But even there, some traders preferred to prototype things in Excel, so that when they came to us to make it production grade, they'd have worked out a lot of the details.

          We showed some of them how to use NeXT's Interface Builder, so they could construct high-fidelity interfaces. But that still didn't let them prototype the math or the data flow, which was a lot more important to them for some things.

          William
        • Mike Dwyer
          OK in that arena it makes total sense. In fact I can almost see letting them wing the math on separate pages, as I have been witness to one too many
          Message 4 of 27 , Jan 6, 2009
          • 0 Attachment

            OK in that arena it makes total sense. In fact I can almost see letting them ‘wing’ the math on separate pages, as I have been witness to one too many mathematical ‘conversations’ that almost needed police response.

             

            As to the aside about the card reader.  I was responding to the “20 years” phrase and immediately had these horrid flashbacks to greenbar templates and report layout grids.  I just don’t want to go through the 12 step process again.

             

            Mike Dwyer
            Principal, Agile Coach

            BigVisible Solutions
            url:    http://www.bigvisible.com

            cell:   (978) 376-4422

            email: mdwyer@...

             

             

            From: William Pietri [mailto:william@...]
            Sent: Tuesday, January 06, 2009 11:53 AM
            To: agile-usability@yahoogroups.com
            Subject: Re: [agile-usability] (Possibly OT) Inline Editing vs. Separate Page

             

            Dave, I think this is quite a good place for your query. I think one of the most interesting issues, and certainly one of the most persistent, is how to manage UI change in agile contexts. I'd love to see more discussion of that.

            A couple of comments to Mike:

            Mike Dwyer wrote:

            Dave

            While I want to agree with you I am not sure what PITA stands for, other than what I sometimes wrap tuna salad in.


            http://www.acronymfinder.com/PITA.html


            I find the use of an excel spreadsheet to be of interest is well.  Can I assume their card reader is waiting for parts?


            Although I understand what you mean, this is surprisingly common. Excel is one of those rare things in which non-developer domain experts can actually build quite a bit of functionality on their own. Then a complex spreadsheet may get adopted by developers for further extension or integration with other software. Perhaps that's through uploading the spreadsheets, generating them, or making calls from a spreadsheet to other systems.

            I once worked for financial traders, an environment in which developers sometimes outnumbered users. But even there, some traders preferred to prototype things in Excel, so that when they came to us to make it production grade, they'd have worked out a lot of the details.

            We showed some of them how to use NeXT's Interface Builder, so they could construct high-fidelity interfaces. But that still didn't let them prototype the math or the data flow, which was a lot more important to them for some things.

            William

          • Dave Rooney
            Hello William, ... Some background info... the business for whom this application is being developed has undergone a Lean transformation. The company that
            Message 5 of 27 , Jan 6, 2009
            • 0 Attachment
              Hello William,

              William Pietri wrote:
              > Although I understand what you mean, this is surprisingly common.
              > Excel is one of those rare things in which non-developer domain
              > experts can actually build quite a bit of functionality on their own.
              > Then a complex spreadsheet may get adopted by developers for further
              > extension or integration with other software. Perhaps that's through
              > uploading the spreadsheets, generating them, or making calls from a
              > spreadsheet to other systems.

              Some background info... the business for whom this application is being
              developed has undergone a Lean transformation. The company that
              facilitated that had the business people use low-fidelity tools like
              Excel in order to get the people to focus on what they were doing rather
              than the tools they were doing it with. This was all quite good! The
              spreadsheets were used to record data off a physical whiteboard, and
              then perform some extensive calculations. One group decided to try out
              a SmartBoard (http://smarttech.com/) to replace the white boards, and to
              do so had to add considerable automation to their version of the
              spreadsheet.

              While this solution worked for that group, the code behind the
              spreadsheet was quite specific and would require significant change to
              be applicable to the other 5 business groups who would need it. Also,
              the contract developer who built the automation left and with him all of
              the knowledge of the internal of the application! So, the decision was
              to replace the spreadsheets with a web app that met the current needs
              for all 6 of the business groups.

              So, the legacy of the Excel application is that it's relatively easy to
              enter data. There are, however, quirks and problems managing the data
              after entry. One person has to spend several hours a week looking after
              the spreadsheet, and has had to rebuild it from scratch a few time owing
              to data corruption.

              The new web app will solve many of the stability issues, but has
              introduced this complaint about the UI. My agile view is that the
              simplest thing that could possibly work is the separate page for
              editing. However, the user's want inline editing. I have suggested a
              spike to explore a couple of options, but I still have considerable
              discomfort with the notion of providing a full Excel-type data entry
              interface. Maybe I'm just lazy! :)

              So given this context, I'm interested to hear what people think about
              inline vs. modal/separate page for data entry from a usuability
              perspective since I believe my view is skewed towards the developer's view.

              Thanks!

              --

              Dave Rooney
              Mayford Technologies
              "Helping you become AGILE... to SURVIVE and THRIVE!"
              http://www.mayford.ca
              http://practicalagility.blogspot.com
              Twitter: daverooneyca
            • Mike Dwyer
              Dave Thanks for the breakdown. Mike Dwyer Principal, Agile Coach BigVisible Solutions url: http://www.bigvisible.com cell:
              Message 6 of 27 , Jan 6, 2009
              • 0 Attachment

                Dave

                Thanks for the breakdown. 

                 

                Mike Dwyer
                Principal, Agile Coach

                BigVisible Solutions
                url:    http://www.bigvisible.com

                cell:   (978) 376-4422

                email: mdwyer@...

                 

                 

                From: Dave Rooney [mailto:dave.rooney@...]
                Sent: Tuesday, January 06, 2009 12:24 PM
                To: agile-usability@yahoogroups.com
                Subject: Re: [agile-usability] Inline Editing vs. Separate Page

                 

                Hello William,

                William Pietri wrote:

                > Although I understand what you mean, this is surprisingly common.
                > Excel is one of those rare things in which non-developer domain
                > experts can actually build quite a bit of functionality on their own.
                > Then a complex spreadsheet may get adopted by developers for further
                > extension or integration with other software. Perhaps that's through
                > uploading the spreadsheets, generating them, or making calls from a
                > spreadsheet to other systems.

                Some background info... the business for whom this application is being
                developed has undergone a Lean transformation. The company that
                facilitated that had the business people use low-fidelity tools like
                Excel in order to get the people to focus on what they were doing rather
                than the tools they were doing it with. This was all quite good! The
                spreadsheets were used to record data off a physical whiteboard, and
                then perform some extensive calculations. One group decided to try out
                a SmartBoard (http://smarttech.com/) to replace the white boards, and to
                do so had to add considerable automation to their version of the
                spreadsheet.

                While this solution worked for that group, the code behind the
                spreadsheet was quite specific and would require significant change to
                be applicable to the other 5 business groups who would need it. Also,
                the contract developer who built the automation left and with him all of
                the knowledge of the internal of the application! So, the decision was
                to replace the spreadsheets with a web app that met the current needs
                for all 6 of the business groups.

                So, the legacy of the Excel application is that it's relatively easy to
                enter data. There are, however, quirks and problems managing the data
                after entry. One person has to spend several hours a week looking after
                the spreadsheet, and has had to rebuild it from scratch a few time owing
                to data corruption.

                The new web app will solve many of the stability issues, but has
                introduced this complaint about the UI. My agile view is that the
                simplest thing that could possibly work is the separate page for
                editing. However, the user's want inline editing. I have suggested a
                spike to explore a couple of options, but I still have considerable
                discomfort with the notion of providing a full Excel-type data entry
                interface. Maybe I'm just lazy! :)

                So given this context, I'm interested to hear what people think about
                inline vs. modal/separate page for data entry from a usuability
                perspective since I believe my view is skewed towards the developer's view.

                Thanks!

                --

                Dave Rooney
                Mayford Technologies
                "Helping you become AGILE... to SURVIVE and THRIVE!"
                http://www.mayford.ca
                http://practicalagility.blogspot.com
                Twitter: daverooneyca

              • Hassan Schroeder
                ... Still don t understand -- discomfort because _______? Inline editing sounds like the right thing to me. What possible reason can there be for continually
                Message 7 of 27 , Jan 6, 2009
                • 0 Attachment
                  On Tue, Jan 6, 2009 at 9:23 AM, Dave Rooney <dave.rooney@...> wrote:

                  > The new web app will solve many of the stability issues, but has
                  > introduced this complaint about the UI. My agile view is that the
                  > simplest thing that could possibly work is the separate page for
                  > editing. However, the user's want inline editing. I have suggested a
                  > spike to explore a couple of options, but I still have considerable
                  > discomfort with the notion of providing a full Excel-type data entry
                  > interface.

                  Still don't understand -- "discomfort" because _______?

                  Inline editing sounds like the right thing to me. What possible reason
                  can there be for continually changing pages back and forth to edit?
                  Clumsy, time-consuming -- I'd push back on that too :-)

                  And as a developer I can't see how providing inline editing is a big
                  deal, either in HTML/JS or (possibly better) Flex.

                  YMMV,
                  --
                  Hassan Schroeder ------------------------ hassan.schroeder@...
                • Dave Rooney
                  ... Simplicity of validation - plain and simple. My experience has been that validation of edits in a data grid is non-trivial, and this is a big, honking
                  Message 8 of 27 , Jan 6, 2009
                  • 0 Attachment
                    Hassan Schroeder wrote:
                    > On Tue, Jan 6, 2009 at 9:23 AM, Dave Rooney <dave.rooney@...> wrote:
                    >
                    >
                    >> The new web app will solve many of the stability issues, but has
                    >> introduced this complaint about the UI. My agile view is that the
                    >> simplest thing that could possibly work is the separate page for
                    >> editing. However, the user's want inline editing. I have suggested a
                    >> spike to explore a couple of options, but I still have considerable
                    >> discomfort with the notion of providing a full Excel-type data entry
                    >> interface.
                    >>
                    >
                    > Still don't understand -- "discomfort" because _______?
                    >
                    > Inline editing sounds like the right thing to me. What possible reason
                    > can there be for continually changing pages back and forth to edit?
                    > Clumsy, time-consuming -- I'd push back on that too :-)
                    >
                    > And as a developer I can't see how providing inline editing is a big
                    > deal, either in HTML/JS or (possibly better) Flex.
                    >
                    > YMMV,
                    >

                    Simplicity of validation - plain and simple. My experience has been
                    that validation of edits in a data grid is non-trivial, and this is a
                    big, honking data grid. Data quality is a big issue with this client
                    right now, and as such validation isn't something on which the team can
                    cut corners.

                    So, it's much less expensive to use either a separate page or modal
                    popup or some other way to edit the data, and leave the grid as a whole
                    read-only.

                    That's me with my crusty-old-developer hat on (crusty developer, not
                    crusty hat!). I'm interested in the usability view of it. I don't
                    disagree that it's clumsy and/or time-consuming, but there's a cost with
                    inline editing... it doesn't come for free. The current Excel model
                    prepopulates some data and has a calendar popup for some cells, but
                    there are data quality issues owing to the lack of overall validation.

                    On the good side, this project has a very good Customer from an agile
                    perspective. He understands quite well that if it takes longer to build
                    inline editing, then something else will have to give in order to hit
                    their target date. I suppose that should direct me towards a spike to
                    better understand the real vs. perceived implications of the different
                    approaches.

                    --

                    Dave Rooney
                    Mayford Technologies
                    "Helping you become AGILE... to SURVIVE and THRIVE!"
                    http://www.mayford.ca
                    http://practicalagility.blogspot.com
                    Twitter: daverooneyca
                  • Hassan Schroeder
                    ... Perhaps I m still under-caffeinated here, but I don t see how editing a cell inline versus going to another page (or popup) to enter a new value changes
                    Message 9 of 27 , Jan 6, 2009
                    • 0 Attachment
                      On Tue, Jan 6, 2009 at 10:30 AM, Dave Rooney <dave.rooney@...> wrote:

                      > Simplicity of validation - plain and simple. My experience has been
                      > that validation of edits in a data grid is non-trivial, and this is a
                      > big, honking data grid. Data quality is a big issue with this client
                      > right now, and as such validation isn't something on which the team can
                      > cut corners.
                      >
                      > So, it's much less expensive to use either a separate page or modal
                      > popup or some other way to edit the data, and leave the grid as a whole
                      > read-only.
                      >
                      > That's me with my crusty-old-developer hat on (crusty developer, not
                      > crusty hat!). I'm interested in the usability view of it. I don't
                      > disagree that it's clumsy and/or time-consuming, but there's a cost with
                      > inline editing... it doesn't come for free.

                      Perhaps I'm still under-caffeinated here, but I don't see how editing
                      a cell inline versus going to another page (or popup) to enter a new
                      value changes the effort involved in "validation" in any way. Same
                      business logic applied, yes?

                      --
                      Hassan Schroeder ------------------------ hassan.schroeder@...
                    • Marjorie H Pries
                      Lacking any more information, I support the in-line faction. What s missing here is any background information about the data that people want to edit. What
                      Message 10 of 27 , Jan 6, 2009
                      • 0 Attachment
                        Lacking any more information, I support the in-line faction.  What's missing here is any background information about the data that people want to edit.  What is the data...that is, what does it mean to them, business-wise and why do they have to edit it?  Who edits it and how often?  When they make an edit, is it because the previous value is incorrect, obsolete or just something that applies to a different case -- in other words, are the edits corrective or additive to a list of likely values or is the editing done in order to update/replace a variable because conditions changed?

                        When this particul data has been editied in the past, how often has the edit been correct or incorrect. (Sometimes a universal problem with data corruption in not applicable to a specific instance; for some things, the user group may be very small and very accurate.)

                        And are we talking about one specific cell in the spreadsheet or any and every cell?  If many cells, then are the situations for editing generally the same for all the cells or are there different motives, users, scenarios, requirements, etc. for each editable thing?

                        Without discussing the actual business problems that get solved by editing the different values in the spreadsheet and the characteristics of those who usually make these edits, how can we arrive a good opinion about usability?  Perhaps it is better to be in-line for some things and via a pop-up or maintenance tool for others.


                        Marjorie H. Pries
                        Support Manager / Utility Infielder
                        ThoughtWorks, Inc.


                        "Don't believe everything you think."
                            --seen on a bumpersticker



                        "Hassan Schroeder" <hassan.schroeder@...>
                        Sent by: agile-usability@yahoogroups.com

                        01/06/2009 12:44 PM

                        Please respond to
                        agile-usability@yahoogroups.com

                        To
                        agile-usability@yahoogroups.com
                        cc
                        Subject
                        Re: [agile-usability] Inline Editing vs. Separate Page






                        On Tue, Jan 6, 2009 at 10:30 AM, Dave Rooney <dave.rooney@...> wrote:

                        > Simplicity of validation - plain and simple. My experience has been
                        > that validation of edits in a data grid is non-trivial, and this is
                        a
                        > big, honking data grid. Data quality is a big issue with this client
                        > right now, and as such validation isn't something on which the team
                        can
                        > cut corners.
                        >
                        > So, it's much less expensive to use either a separate page or modal
                        > popup or some other way to edit the data, and leave the grid as a
                        whole
                        > read-only.
                        >
                        > That's me with my crusty-old-developer hat on (crusty developer, not
                        > crusty hat!). I'm interested in the usability view of it. I don't
                        > disagree that it's clumsy and/or time-consuming, but there's a cost
                        with
                        > inline editing... it doesn't come for free.

                        Perhaps I'm still under-caffeinated here, but I don't see how editing
                        a cell inline versus going to another page (or popup) to enter a new
                        value changes the effort involved in "validation" in any way. Same
                        business logic applied, yes?

                        --
                        Hassan Schroeder ------------------------
                        hassan.schroeder@...


                      • Dave Rooney
                        ... Hello Marjorie, Thank you for your response - it s really what I was looking for, i.e. the reasons behind why one option would be preferable. This
                        Message 11 of 27 , Jan 6, 2009
                        • 0 Attachment
                          Marjorie H Pries wrote:
                          > Lacking any more information, I support the in-line faction. What's
                          > missing here is any background information about the data that people
                          > want to edit. What is the data...that is, what does it mean to them,
                          > business-wise and why do they have to edit it? Who edits it and how
                          > often? When they make an edit, is it because the previous value is
                          > incorrect, obsolete or just something that applies to a different case
                          > -- in other words, are the edits corrective or additive to a list of
                          > likely values or is the editing done in order to update/replace a
                          > variable because conditions changed?
                          >
                          > When this particul data has been editied in the past, how often has
                          > the edit been correct or incorrect. (Sometimes a universal problem
                          > with data corruption in not applicable to a specific instance; for
                          > some things, the user group may be very small and very accurate.)
                          >
                          > And are we talking about one specific cell in the spreadsheet or any
                          > and every cell? If many cells, then are the situations for editing
                          > generally the same for all the cells or are there different motives,
                          > users, scenarios, requirements, etc. for each editable thing?
                          >
                          > Without discussing the actual business problems that get solved by
                          > editing the different values in the spreadsheet and the
                          > characteristics of those who usually make these edits, how can we
                          > arrive a good opinion about usability? Perhaps it is better to be
                          > in-line for some things and via a pop-up or maintenance tool for others.

                          Hello Marjorie,

                          Thank you for your response - it's really what I was looking for, i.e.
                          the reasons behind why one option would be preferable.

                          This spreadsheet application is used by "work cells" during their daily
                          huddle in which the work that they're doing is actively discussed.
                          There are on the order of 20 cells per row that can be updated at any
                          given time, although perhaps a quarter are automatically populated when
                          one initial cell is given data. The majority of the cells that are
                          changed have date values, and there is a certain amount of
                          "scenario-based editing", i.e. "If we do this on this date [user enters
                          a date], then we could push this item up to this date [user enters
                          another date on another row]". So, the data can be quite dynamic
                          although many of these scenarios may never actually be saved since the
                          spreadsheet isn't typically saved until the users are done.

                          The spreadsheet itself can contain anywhere from 5 to 40 rows of data
                          per sheet depending on the team. My concern is that with a worst case
                          of 40 rows, with 20 potentially editable cells per row, and of those 20
                          there are probably 10 cells which are slated to have validation rules
                          that require reading related cells in the same row, it's going to be
                          quite complex from a development perspective. That complexity could be
                          alleviated by using a more modal approach.

                          As I've said before, though, I'm seeing this from a (whiny, crusty, old)
                          developer's perspective. Your questions make me think that perhaps it
                          may be worth the extra development and testing effort to go with the
                          inline approach.

                          --

                          Dave Rooney
                          Mayford Technologies
                          "Helping you become AGILE... to SURVIVE and THRIVE!"
                          http://www.mayford.ca
                          http://practicalagility.blogspot.com
                          Twitter: daverooneyca
                        • Dave Rooney
                          ... Yes, the same business logic, but as I said in my response to Marjorie there are up to 40 rows with 20 editable cells with about 10 of those having
                          Message 12 of 27 , Jan 6, 2009
                          • 0 Attachment
                            Hassan Schroeder wrote:
                            > Perhaps I'm still under-caffeinated here, but I don't see how editing
                            > a cell inline versus going to another page (or popup) to enter a new
                            > value changes the effort involved in "validation" in any way. Same
                            > business logic applied, yes?
                            >

                            Yes, the same business logic, but as I said in my response to Marjorie
                            there are up to 40 rows with 20 editable cells with about 10 of those
                            having validation requiring related cells in the same row.

                            Is it insurmountable? No. Is it trivial? Definitely not.

                            This may be a case where the development cost may be worth it to the
                            Customer and end users.

                            --

                            Dave Rooney
                            Mayford Technologies
                            "Helping you become AGILE... to SURVIVE and THRIVE!"
                            http://www.mayford.ca
                            http://practicalagility.blogspot.com
                            Twitter: daverooneyca
                          • Marjorie H Pries
                            In response to Dave below, it just occurred to me that this flavor of validation requirement might be satisfied with the old-fashioned Do it! or Calculate
                            Message 13 of 27 , Jan 6, 2009
                            • 0 Attachment
                              In response to Dave below,  it just occurred to me that this flavor of validation requirement might be satisfied with the old-fashioned "Do it!" or "Calculate" button.  I not entirely clear how much cell b or e might depend on a valid value in cell a or d but maybe in this case, the users could plug in all their dates without triggering any validations until they explicitly hit a "Calculate" button or widget.

                              If you can defer validations in this way, perhaps it will make some things easier. From an end-user view, the concept should feel a lot more natural than many pop-ups; especially if they get a list of issues to correct once they hit the Calculate button.



                              Marjorie H. Pries
                              Support Manager / Utility Infielder

                              ThoughtWorks, Inc.
                              http://www.thoughtworks.com

                              cell 312.925.1532
                              desk: 312.373.8643

                              "Don't believe everything you think."
                                  --seen on a bumpersticker



                              Dave Rooney <dave.rooney@...>
                              Sent by: agile-usability@yahoogroups.com

                              01/06/2009 01:22 PM

                              Please respond to
                              agile-usability@yahoogroups.com

                              To
                              agile-usability@yahoogroups.com
                              cc
                              Subject
                              Re: [agile-usability] Inline Editing vs. Separate Page






                              Hassan Schroeder wrote:

                              > Perhaps I'm still under-caffeinated here, but I don't see how editing
                              > a cell inline versus going to another page (or popup) to enter a new
                              > value changes the effort involved in "validation" in any
                              way. Same
                              > business logic applied, yes?
                              >

                              Yes, the same business logic, but as I said in my response to Marjorie
                              there are up to 40 rows with 20 editable cells with about 10 of those
                              having validation requiring related cells in the same row.

                              Is it insurmountable? No. Is it trivial? Definitely not.

                              This may be a case where the development cost may be worth it to the
                              Customer and end users.

                              --

                              Dave Rooney
                              Mayford Technologies
                              "Helping you become AGILE... to SURVIVE and THRIVE!"

                              http://www.mayford.ca
                              http://practicalagility.blogspot.com
                              Twitter: daverooneyca


                            • Hassan Schroeder
                              ... Sorry, still not seeing the problem -- the amount of data involved is the same regardless of the choice of input method, is it not? ... I don t see how
                              Message 14 of 27 , Jan 6, 2009
                              • 0 Attachment
                                On Tue, Jan 6, 2009 at 11:22 AM, Dave Rooney <dave.rooney@...> wrote:

                                > Yes, the same business logic, but as I said in my response to Marjorie
                                > there are up to 40 rows with 20 editable cells with about 10 of those
                                > having validation requiring related cells in the same row.

                                Sorry, still not seeing the problem -- the amount of data involved is
                                the same regardless of the choice of input method, is it not?

                                > Is it insurmountable? No. Is it trivial? Definitely not.

                                I don't see how "mode of input" relates to "difficulty of implementation"
                                of a back-end process (validation in this case).

                                If the "easiest possible thing that will work" /from the user's perspective/
                                is inline editing, and any backend considerations are /independent/ of
                                that, it would seem the answer is apparent :-)

                                IMHO!
                                --
                                Hassan Schroeder ------------------------ hassan.schroeder@...
                              • marc mcneill
                                At the last iteration demo, one comment was made that the new web application s UI has a separate page for editing some data that is currently edited in
                                Message 15 of 27 , Jan 6, 2009
                                • 0 Attachment
                                  "At the last iteration demo, one comment was made that the new
                                  web application's UI has a separate page for editing some data that is
                                  currently edited "in place" in the spreadsheet. The developers are
                                  being told that there will definitely be some pushback to using a
                                  separate page."

                                  The users are used to in-cell editing using excel, they change the data and it is updated.  This is a fast and efficient process.  Forcing them to open up a separate page for editing will significantly slow down their ability to complete their processes and pushback is unsurprising.  If one of the key usability heuristics is 'speed', then clearly a separate page is to be avoided. 


                                  On Wed, Jan 7, 2009 at 1:02 AM, Mike Dwyer <mdwyer@...> wrote:

                                  OK in that arena it makes total sense. In fact I can almost see letting them 'wing' the math on separate pages, as I have been witness to one too many mathematical 'conversations' that almost needed police response.

                                   

                                  As to the aside about the card reader.  I was responding to the "20 years" phrase and immediately had these horrid flashbacks to greenbar templates and report layout grids.  I just don't want to go through the 12 step process again.

                                   

                                  Mike Dwyer
                                  Principal, Agile Coach

                                  BigVisible Solutions
                                  url:    http://www.bigvisible.com

                                  cell:   (978) 376-4422

                                  email: mdwyer@...

                                   

                                   

                                  From: William Pietri [mailto:william@...]
                                  Sent: Tuesday, January 06, 2009 11:53 AM

                                  Subject: Re: [agile-usability] (Possibly OT) Inline Editing vs. Separate Page

                                   

                                  Dave, I think this is quite a good place for your query. I think one of the most interesting issues, and certainly one of the most persistent, is how to manage UI change in agile contexts. I'd love to see more discussion of that.

                                  A couple of comments to Mike:

                                  Mike Dwyer wrote:

                                  Dave

                                  While I want to agree with you I am not sure what PITA stands for, other than what I sometimes wrap tuna salad in.


                                  http://www.acronymfinder.com/PITA.html


                                  I find the use of an excel spreadsheet to be of interest is well.  Can I assume their card reader is waiting for parts?


                                  Although I understand what you mean, this is surprisingly common. Excel is one of those rare things in which non-developer domain experts can actually build quite a bit of functionality on their own. Then a complex spreadsheet may get adopted by developers for further extension or integration with other software. Perhaps that's through uploading the spreadsheets, generating them, or making calls from a spreadsheet to other systems.

                                  I once worked for financial traders, an environment in which developers sometimes outnumbered users. But even there, some traders preferred to prototype things in Excel, so that when they came to us to make it production grade, they'd have worked out a lot of the details.

                                  We showed some of them how to use NeXT's Interface Builder, so they could construct high-fidelity interfaces. But that still didn't let them prototype the math or the data flow, which was a lot more important to them for some things.

                                  William




                                  --
                                  http://www.dancingmango.com/blog/
                                • Faith Peterson
                                  On Tue, Jan 6, 2009 at 1:19 PM, Dave Rooney wrote: ... I m seeing this from a (whiny, crusty, old) developer s perspective. In general
                                  Message 16 of 27 , Jan 6, 2009
                                  • 0 Attachment
                                    On Tue, Jan 6, 2009 at 1:19 PM, Dave Rooney <dave.rooney@...> wrote:
                                    ... I'm seeing this from a (whiny, crusty, old) developer's perspective.

                                    In general I'm also in the not-on-another-page camp. To approach the "why do the users care so much about this anyway, I don't get it" issue, maybe there is a thought exercise that will help. This is an imperfect example, but I think it might help somewhat.

                                    Imagine your IDE is a Web app. Now imagine that every time you write a new class you have to go to a new page to create it. Then you have to go to a new page for each method you write. You have to go to a new page to add or edit each variable declaration.

                                    If you're writing tests, you have to go to a new page to define each new test. Then you have to go to a new page to add or edit the data for each case you want to test. You have to go to a new page to examine the result of each execution of the test.

                                    I'm not a developer. I'm sure those of you who are can re-calibrate those examples and think of many more details you have to define or change in these and other situations (builds, code repository management).

                                    I'm not sure if this helps. A well-developed sense of empathy will take you a long way with or without usability expertise being brought to bear. The key is finding an analogous task you understand, one that is as central to your work as the task they use this application for is to them. Then tap into how acceptable you would find the kind of solution that's under discussion.

                                    If any of us can do that you'll take a giant step toward partnering with rather than supplying software to your customers. Not to take anything away from the real expertise and education many user experience designers bring to the party, of course.


                                    Faith Peterson | f.a.peterson@...
                                    LinkedinPlaxodel.icio.usTwitter
                                  • Dave Rooney
                                    ... I don t disagree, although there is a corporate mandate to improve data quality. The Excel application has had a number of problems with incorrectly
                                    Message 17 of 27 , Jan 6, 2009
                                    • 0 Attachment
                                      marc mcneill wrote:
                                      > "At the last iteration demo, one comment was made that the new
                                      > web application's UI has a separate page for editing some data that is
                                      > currently edited "in place" in the spreadsheet. The developers are
                                      > being told that there will definitely be some pushback to using a
                                      > separate page."
                                      >
                                      > The users are used to in-cell editing using excel, they change the
                                      > data and it is updated. This is a fast and efficient process.
                                      > Forcing them to open up a separate page for editing will significantly
                                      > slow down their ability to complete their processes and pushback is
                                      > unsurprising. If one of the key usability heuristics is 'speed', then
                                      > clearly a separate page is to be avoided.

                                      I don't disagree, although there is a corporate mandate to improve data
                                      quality. The Excel application has had a number of problems with
                                      incorrectly entered data, including dates that wouldn't pass a simple
                                      validation sanity check (e.g. year was 2908 instead of 2008).

                                      --

                                      Dave Rooney
                                      Mayford Technologies
                                      "Helping you become AGILE... to SURVIVE and THRIVE!"
                                      http://www.mayford.ca
                                      http://practicalagility.blogspot.com
                                      Twitter: daverooneyca
                                    • Jon Kern
                                      re: So given this context, I m interested to hear what people think about inline vs. modal/separate page for data entry from a usability perspective since I
                                      Message 18 of 27 , Jan 6, 2009
                                      • 0 Attachment
                                        re: " So given this context, I'm interested to hear what people think about
                                        inline vs. modal/separate page for data entry from a usability
                                        perspective since I believe my view is skewed towards the developer's view."

                                        I have found that users really enjoy inline editing on their webpages.
                                        Or at least a simple transition between going from the "view" of the
                                        page to being able to "edit" the page. While sometimes entry of the data
                                        (e.g., an image requires browse/upload) is different than the display
                                        (just the image or a thumbnail), users seem to prefer "in-line editing"
                                        over going to some other admin-like page to control content.

                                        I think the basic reason is -- like in document authoring -- when you
                                        see a page that needs editing, it makes sense to edit it right where you
                                        are versus going off to some other unrelated place. Many "separate"
                                        techniques -- or admin style editing -- require the user to often
                                        navigate around the "document" a different way than the way the page is
                                        natively displayed. This is a contextual mismatch for most users I believe.

                                        A very simplistic example can be seen here (not at all fancy, and I
                                        noticed an error in field order :-o ):

                                        Edit View
                                        <http://technicaldebt.wetpaint.com/photo/3447630/Inline+Editing+Example+-+Edit+View>

                                        Normal View
                                        <http://technicaldebt.wetpaint.com/photo/3447629/Inline+Editing+Example+-+User%27s+View>

                                        Hope the links work.

                                        jon
                                        blog: http://technicaldebt.com
                                        profile: http://www.linkedin.com/in/jonkern



                                        Dave Rooney said the following on 1/6/09 12:23 PM:
                                        >
                                        > Hello William,
                                        >
                                        > William Pietri wrote:
                                        > > Although I understand what you mean, this is surprisingly common.
                                        > > Excel is one of those rare things in which non-developer domain
                                        > > experts can actually build quite a bit of functionality on their own.
                                        > > Then a complex spreadsheet may get adopted by developers for further
                                        > > extension or integration with other software. Perhaps that's through
                                        > > uploading the spreadsheets, generating them, or making calls from a
                                        > > spreadsheet to other systems.
                                        >
                                        > Some background info... the business for whom this application is being
                                        > developed has undergone a Lean transformation. The company that
                                        > facilitated that had the business people use low-fidelity tools like
                                        > Excel in order to get the people to focus on what they were doing rather
                                        > than the tools they were doing it with. This was all quite good! The
                                        > spreadsheets were used to record data off a physical whiteboard, and
                                        > then perform some extensive calculations. One group decided to try out
                                        > a SmartBoard (http://smarttech.com/ <http://smarttech.com/>) to
                                        > replace the white boards, and to
                                        > do so had to add considerable automation to their version of the
                                        > spreadsheet.
                                        >
                                        > While this solution worked for that group, the code behind the
                                        > spreadsheet was quite specific and would require significant change to
                                        > be applicable to the other 5 business groups who would need it. Also,
                                        > the contract developer who built the automation left and with him all of
                                        > the knowledge of the internal of the application! So, the decision was
                                        > to replace the spreadsheets with a web app that met the current needs
                                        > for all 6 of the business groups.
                                        >
                                        > So, the legacy of the Excel application is that it's relatively easy to
                                        > enter data. There are, however, quirks and problems managing the data
                                        > after entry. One person has to spend several hours a week looking after
                                        > the spreadsheet, and has had to rebuild it from scratch a few time owing
                                        > to data corruption.
                                        >
                                        > The new web app will solve many of the stability issues, but has
                                        > introduced this complaint about the UI. My agile view is that the
                                        > simplest thing that could possibly work is the separate page for
                                        > editing. However, the user's want inline editing. I have suggested a
                                        > spike to explore a couple of options, but I still have considerable
                                        > discomfort with the notion of providing a full Excel-type data entry
                                        > interface. Maybe I'm just lazy! :)
                                        >
                                        > So given this context, I'm interested to hear what people think about
                                        > inline vs. modal/separate page for data entry from a usuability
                                        > perspective since I believe my view is skewed towards the developer's
                                        > view.
                                        >
                                        > Thanks!
                                        >
                                        > --
                                        >
                                        > Dave Rooney
                                        > Mayford Technologies
                                        > "Helping you become AGILE... to SURVIVE and THRIVE!"
                                        > http://www.mayford.ca <http://www.mayford.ca>
                                        > http://practicalagility.blogspot.com
                                        > <http://practicalagility.blogspot.com>
                                        > Twitter: daverooneyca
                                        >
                                        >
                                      • William Pietri
                                        ... When you describe it that way, that makes a lot of sense. I think Flickr was the first site I saw to get that really right for me. If you want to edit a
                                        Message 19 of 27 , Jan 6, 2009
                                        • 0 Attachment
                                          Jon Kern wrote:
                                          > I have found that users really enjoy inline editing on their webpages.
                                          > Or at least a simple transition between going from the "view" of the
                                          > page to being able to "edit" the page. While sometimes entry of the data
                                          > (e.g., an image requires browse/upload) is different than the display
                                          > (just the image or a thumbnail), users seem to prefer "in-line editing"
                                          > over going to some other admin-like page to control content.
                                          >
                                          > I think the basic reason is -- like in document authoring -- when you
                                          > see a page that needs editing, it makes sense to edit it right where you
                                          > are versus going off to some other unrelated place.


                                          When you describe it that way, that makes a lot of sense.

                                          I think Flickr was the first site I saw to get that really right for me.
                                          If you want to edit a photo title or description, you just click on it,
                                          and it does some AJAX magic to make the field editable. (As long as you
                                          have access, that is.) There's no need to figure out which affordance to
                                          click on, what the right menu choice is, or what tab to go to. It was
                                          such a superior interaction that my opinion on JavaScript changed 180
                                          degrees in an instant.

                                          And from the development perspective, that can sometimes be easier than
                                          a separate interface, especially one where you can edit a bunch of
                                          things before submitting. If the user's only editing one element at a
                                          time as they work inline, then although you have to handle a bunch of
                                          different editing operations, they're all clear and sequential, rather
                                          than complex and interdependent.

                                          If I were you, Dave, I'd try sketching a few different possibilities,
                                          perhaps as part of a joint design session with the users. And yes, I'd
                                          agree that a spike beforehand might be helpful. Then you can go off and
                                          estimate each set of options. If nothing else, this will let you have
                                          new and interesting disagreements, rather than one you perhaps have had
                                          your fill of.

                                          William
                                        • George Dinwiddie
                                          ... http://www.urbandictionary.com/define.php?term=PITA -- ... * George Dinwiddie * http://blog.gdinwiddie.com Software Development
                                          Message 20 of 27 , Jan 7, 2009
                                          • 0 Attachment
                                            Mike Dwyer wrote:
                                            > While I want to agree with you I am not sure what PITA stands for, other
                                            > than what I sometimes wrap tuna salad in.

                                            http://www.urbandictionary.com/define.php?term=PITA

                                            --
                                            ----------------------------------------------------------------------
                                            * George Dinwiddie * http://blog.gdinwiddie.com
                                            Software Development http://www.idiacomputing.com
                                            Consultant and Coach http://www.agilemaryland.org
                                            ----------------------------------------------------------------------
                                          • Dave Rooney
                                            Yeah, I believe I m going to have to get past *my* issues and just do it. I had thought about switching from view to edit, but again my inherent laziness was
                                            Message 21 of 27 , Jan 7, 2009
                                            • 0 Attachment
                                              Yeah, I believe I'm going to have to get past *my* issues and just do
                                              it. I had thought about switching from view to edit, but again my
                                              inherent laziness was kicking in.

                                              BTW, I've started using a tool called Balsamiq Mockups
                                              (http://www.balsamiq.com/products/mockups) for sketching UI's. It's way
                                              cool - very easy to use and retains that "sketch" look and feel.

                                              Thanks all for the input. It may not necessarily what I wanted to hear,
                                              but probably what I needed! :)

                                              --

                                              Dave Rooney
                                              Mayford Technologies
                                              "Helping you become AGILE... to SURVIVE and THRIVE!"
                                              http://www.mayford.ca
                                              http://practicalagility.blogspot.com
                                              Twitter: daverooneyca


                                              William Pietri wrote:
                                              > Jon Kern wrote:
                                              >
                                              >> I have found that users really enjoy inline editing on their webpages.
                                              >> Or at least a simple transition between going from the "view" of the
                                              >> page to being able to "edit" the page. While sometimes entry of the data
                                              >> (e.g., an image requires browse/upload) is different than the display
                                              >> (just the image or a thumbnail), users seem to prefer "in-line editing"
                                              >> over going to some other admin-like page to control content.
                                              >>
                                              >> I think the basic reason is -- like in document authoring -- when you
                                              >> see a page that needs editing, it makes sense to edit it right where you
                                              >> are versus going off to some other unrelated place.
                                              >>
                                              >
                                              >
                                              > When you describe it that way, that makes a lot of sense.
                                              >
                                              > I think Flickr was the first site I saw to get that really right for me.
                                              > If you want to edit a photo title or description, you just click on it,
                                              > and it does some AJAX magic to make the field editable. (As long as you
                                              > have access, that is.) There's no need to figure out which affordance to
                                              > click on, what the right menu choice is, or what tab to go to. It was
                                              > such a superior interaction that my opinion on JavaScript changed 180
                                              > degrees in an instant.
                                              >
                                              > And from the development perspective, that can sometimes be easier than
                                              > a separate interface, especially one where you can edit a bunch of
                                              > things before submitting. If the user's only editing one element at a
                                              > time as they work inline, then although you have to handle a bunch of
                                              > different editing operations, they're all clear and sequential, rather
                                              > than complex and interdependent.
                                              >
                                              > If I were you, Dave, I'd try sketching a few different possibilities,
                                              > perhaps as part of a joint design session with the users. And yes, I'd
                                              > agree that a spike beforehand might be helpful. Then you can go off and
                                              > estimate each set of options. If nothing else, this will let you have
                                              > new and interesting disagreements, rather than one you perhaps have had
                                              > your fill of.
                                              >
                                            • Jon Kern
                                              yeah, i saw balsamiq when i was perusing plug-ins for the wiki/issue tracker i use (confluence & jira) and it did look way cool. Are you using desktop, or a
                                              Message 22 of 27 , Jan 7, 2009
                                              • 0 Attachment
                                                yeah, i saw balsamiq when i was perusing plug-ins for the wiki/issue
                                                tracker i use (confluence & jira) and it did look way cool.

                                                Are you using desktop, or a plug-in?

                                                jon
                                                blog: http://technicaldebt.com
                                                profile: http://www.linkedin.com/in/jonkern



                                                Dave Rooney said the following on 1/7/09 7:54 AM:
                                                >
                                                > Yeah, I believe I'm going to have to get past *my* issues and just do
                                                > it. I had thought about switching from view to edit, but again my
                                                > inherent laziness was kicking in.
                                                >
                                                > BTW, I've started using a tool called Balsamiq Mockups
                                                > (http://www.balsamiq.com/products/mockups
                                                > <http://www.balsamiq.com/products/mockups>) for sketching UI's. It's way
                                                > cool - very easy to use and retains that "sketch" look and feel.
                                                >
                                                > Thanks all for the input. It may not necessarily what I wanted to hear,
                                                > but probably what I needed! :)
                                                >
                                                > --
                                                >
                                                > Dave Rooney
                                                > Mayford Technologies
                                                > "Helping you become AGILE... to SURVIVE and THRIVE!"
                                                > http://www.mayford.ca <http://www.mayford.ca>
                                                > http://practicalagility.blogspot.com
                                                > <http://practicalagility.blogspot.com>
                                                > Twitter: daverooneyca
                                                >
                                                > William Pietri wrote:
                                                > > Jon Kern wrote:
                                                > >
                                                > >> I have found that users really enjoy inline editing on their webpages.
                                                > >> Or at least a simple transition between going from the "view" of the
                                                > >> page to being able to "edit" the page. While sometimes entry of the
                                                > data
                                                > >> (e.g., an image requires browse/upload) is different than the display
                                                > >> (just the image or a thumbnail), users seem to prefer "in-line
                                                > editing"
                                                > >> over going to some other admin-like page to control content.
                                                > >>
                                                > >> I think the basic reason is -- like in document authoring -- when you
                                                > >> see a page that needs editing, it makes sense to edit it right
                                                > where you
                                                > >> are versus going off to some other unrelated place.
                                                > >>
                                                > >
                                                > >
                                                > > When you describe it that way, that makes a lot of sense.
                                                > >
                                                > > I think Flickr was the first site I saw to get that really right for
                                                > me.
                                                > > If you want to edit a photo title or description, you just click on it,
                                                > > and it does some AJAX magic to make the field editable. (As long as you
                                                > > have access, that is.) There's no need to figure out which
                                                > affordance to
                                                > > click on, what the right menu choice is, or what tab to go to. It was
                                                > > such a superior interaction that my opinion on JavaScript changed 180
                                                > > degrees in an instant.
                                                > >
                                                > > And from the development perspective, that can sometimes be easier than
                                                > > a separate interface, especially one where you can edit a bunch of
                                                > > things before submitting. If the user's only editing one element at a
                                                > > time as they work inline, then although you have to handle a bunch of
                                                > > different editing operations, they're all clear and sequential, rather
                                                > > than complex and interdependent.
                                                > >
                                                > > If I were you, Dave, I'd try sketching a few different possibilities,
                                                > > perhaps as part of a joint design session with the users. And yes, I'd
                                                > > agree that a spike beforehand might be helpful. Then you can go off and
                                                > > estimate each set of options. If nothing else, this will let you have
                                                > > new and interesting disagreements, rather than one you perhaps have had
                                                > > your fill of.
                                                > >
                                                >
                                                >
                                              • Dave Rooney
                                                I m using the desktop version. Tried it out for about half an hour, then paid the $79 USD for it. Well worth the money, IMO. -- Dave Rooney Mayford
                                                Message 23 of 27 , Jan 7, 2009
                                                • 0 Attachment
                                                  I'm using the desktop version. Tried it out for about half an hour,
                                                  then paid the $79 USD for it. Well worth the money, IMO.

                                                  --

                                                  Dave Rooney
                                                  Mayford Technologies
                                                  "Helping you become AGILE... to SURVIVE and THRIVE!"
                                                  http://www.mayford.ca
                                                  http://practicalagility.blogspot.com
                                                  Twitter: daverooneyca


                                                  Jon Kern wrote:
                                                  > yeah, i saw balsamiq when i was perusing plug-ins for the wiki/issue
                                                  > tracker i use (confluence & jira) and it did look way cool.
                                                  >
                                                  > Are you using desktop, or a plug-in?
                                                  >
                                                  > jon
                                                  > blog: http://technicaldebt.com
                                                  > profile: http://www.linkedin.com/in/jonkern
                                                  >
                                                  >
                                                  >
                                                  > Dave Rooney said the following on 1/7/09 7:54 AM:
                                                  >
                                                  >> Yeah, I believe I'm going to have to get past *my* issues and just do
                                                  >> it. I had thought about switching from view to edit, but again my
                                                  >> inherent laziness was kicking in.
                                                  >>
                                                  >> BTW, I've started using a tool called Balsamiq Mockups
                                                  >> (http://www.balsamiq.com/products/mockups
                                                  >> <http://www.balsamiq.com/products/mockups>) for sketching UI's. It's way
                                                  >> cool - very easy to use and retains that "sketch" look and feel.
                                                  >>
                                                  >> Thanks all for the input. It may not necessarily what I wanted to hear,
                                                  >> but probably what I needed! :)
                                                  >>
                                                  >> --
                                                  >>
                                                  >> Dave Rooney
                                                  >> Mayford Technologies
                                                  >> "Helping you become AGILE... to SURVIVE and THRIVE!"
                                                  >> http://www.mayford.ca <http://www.mayford.ca>
                                                  >> http://practicalagility.blogspot.com
                                                  >> <http://practicalagility.blogspot.com>
                                                  >> Twitter: daverooneyca
                                                  >>
                                                  >> William Pietri wrote:
                                                  >>
                                                  >>> Jon Kern wrote:
                                                  >>>
                                                  >>>
                                                  >>>> I have found that users really enjoy inline editing on their webpages.
                                                  >>>> Or at least a simple transition between going from the "view" of the
                                                  >>>> page to being able to "edit" the page. While sometimes entry of the
                                                  >>>>
                                                  >> data
                                                  >>
                                                  >>>> (e.g., an image requires browse/upload) is different than the display
                                                  >>>> (just the image or a thumbnail), users seem to prefer "in-line
                                                  >>>>
                                                  >> editing"
                                                  >>
                                                  >>>> over going to some other admin-like page to control content.
                                                  >>>>
                                                  >>>> I think the basic reason is -- like in document authoring -- when you
                                                  >>>> see a page that needs editing, it makes sense to edit it right
                                                  >>>>
                                                  >> where you
                                                  >>
                                                  >>>> are versus going off to some other unrelated place.
                                                  >>>>
                                                  >>>>
                                                  >>> When you describe it that way, that makes a lot of sense.
                                                  >>>
                                                  >>> I think Flickr was the first site I saw to get that really right for
                                                  >>>
                                                  >> me.
                                                  >>
                                                  >>> If you want to edit a photo title or description, you just click on it,
                                                  >>> and it does some AJAX magic to make the field editable. (As long as you
                                                  >>> have access, that is.) There's no need to figure out which
                                                  >>>
                                                  >> affordance to
                                                  >>
                                                  >>> click on, what the right menu choice is, or what tab to go to. It was
                                                  >>> such a superior interaction that my opinion on JavaScript changed 180
                                                  >>> degrees in an instant.
                                                  >>>
                                                  >>> And from the development perspective, that can sometimes be easier than
                                                  >>> a separate interface, especially one where you can edit a bunch of
                                                  >>> things before submitting. If the user's only editing one element at a
                                                  >>> time as they work inline, then although you have to handle a bunch of
                                                  >>> different editing operations, they're all clear and sequential, rather
                                                  >>> than complex and interdependent.
                                                  >>>
                                                  >>> If I were you, Dave, I'd try sketching a few different possibilities,
                                                  >>> perhaps as part of a joint design session with the users. And yes, I'd
                                                  >>> agree that a spike beforehand might be helpful. Then you can go off and
                                                  >>> estimate each set of options. If nothing else, this will let you have
                                                  >>> new and interesting disagreements, rather than one you perhaps have had
                                                  >>> your fill of.
                                                  >>>
                                                  >>>
                                                  >>
                                                  >>
                                                  >
                                                  > ------------------------------------
                                                  >
                                                  > Yahoo! Groups Links
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >
                                                • fitzgeraldsteele
                                                  I thought Faith gave excellent advice...empathy is a key tool in user experience evaluation. So it appears the group is, in general, in favor of inline editing
                                                  Message 24 of 27 , Jan 7, 2009
                                                  • 0 Attachment
                                                    I thought Faith gave excellent advice...empathy is a key tool in user
                                                    experience evaluation.

                                                    So it appears the group is, in general, in favor of inline editing where
                                                    possible. I'm thinking about Excel's cell validation functionality,
                                                    which doesn't have the best experience in my mind. You can define rules
                                                    for a cell, but the rules only get validated when you're done editing
                                                    the cell. And, you get an ugly modal error message.

                                                    There must be some kind of web2.0-y way of providing ongoing feedback as
                                                    to whether the cell contents are valid. Has anyone seen any examples of
                                                    this type of inline cell validation anywhere?

                                                    Someone mentioned Flickr...but that's mostly unvalidated text data.

                                                    The closest thing I can think of is http://www.mint.com, an online
                                                    personal finance site. It gives a standard table view of your
                                                    transactions. When you click on a row, the fields turn editable.
                                                    Additional information that might otherwise appear on a separate edit
                                                    page is instead provided in context in a layer that appears under the
                                                    cell. That might be a model you could use.

                                                    Any others?

                                                    Also, check out the jQuery Validation Plugin.
                                                    http://bassistance.de/jquery-plugins/jquery-plugin-validation/

                                                    This has been an interesting discussion...thanks everyone!

                                                    --- In agile-usability@yahoogroups.com, William Pietri <william@...>
                                                    wrote:
                                                    >
                                                    > Jon Kern wrote:
                                                    > > I have found that users really enjoy inline editing on their
                                                    webpages.
                                                    > > Or at least a simple transition between going from the "view" of the
                                                    > > page to being able to "edit" the page. While sometimes entry of the
                                                    data
                                                    > > (e.g., an image requires browse/upload) is different than the
                                                    display
                                                    > > (just the image or a thumbnail), users seem to prefer "in-line
                                                    editing"
                                                    > > over going to some other admin-like page to control content.
                                                    > >
                                                    > > I think the basic reason is -- like in document authoring -- when
                                                    you
                                                    > > see a page that needs editing, it makes sense to edit it right where
                                                    you
                                                    > > are versus going off to some other unrelated place.
                                                    >
                                                    >
                                                    > When you describe it that way, that makes a lot of sense.
                                                    >
                                                    > I think Flickr was the first site I saw to get that really right for
                                                    me.
                                                    > If you want to edit a photo title or description, you just click on
                                                    it,
                                                    > and it does some AJAX magic to make the field editable. (As long as
                                                    you
                                                    > have access, that is.) There's no need to figure out which affordance
                                                    to
                                                    > click on, what the right menu choice is, or what tab to go to. It was
                                                    > such a superior interaction that my opinion on JavaScript changed 180
                                                    > degrees in an instant.
                                                    >
                                                    > And from the development perspective, that can sometimes be easier
                                                    than
                                                    > a separate interface, especially one where you can edit a bunch of
                                                    > things before submitting. If the user's only editing one element at a
                                                    > time as they work inline, then although you have to handle a bunch of
                                                    > different editing operations, they're all clear and sequential, rather
                                                    > than complex and interdependent.
                                                    >
                                                    > If I were you, Dave, I'd try sketching a few different possibilities,
                                                    > perhaps as part of a joint design session with the users. And yes, I'd
                                                    > agree that a spike beforehand might be helpful. Then you can go off
                                                    and
                                                    > estimate each set of options. If nothing else, this will let you have
                                                    > new and interesting disagreements, rather than one you perhaps have
                                                    had
                                                    > your fill of.
                                                    >
                                                    > William
                                                    >
                                                  • Jon Kern
                                                    yeah... another fun and simple tool that i have been messing around with is gliffy for drawing simple diagrams one thing i really enjoy about web-based tools
                                                    Message 25 of 27 , Jan 7, 2009
                                                    • 0 Attachment
                                                      yeah...

                                                      another fun and simple tool that i have been messing around with is
                                                      gliffy for drawing simple diagrams

                                                      one thing i really enjoy about web-based tools is to see new features,
                                                      little niceties, good improvements... pop up frequently.

                                                      jon
                                                      blog: http://technicaldebt.com
                                                      profile: http://www.linkedin.com/in/jonkern



                                                      Dave Rooney said the following on 1/7/09 9:01 AM:
                                                      >
                                                      > I'm using the desktop version. Tried it out for about half an hour,
                                                      > then paid the $79 USD for it. Well worth the money, IMO.
                                                      >
                                                      > --
                                                      >
                                                      > Dave Rooney
                                                      > Mayford Technologies
                                                      > "Helping you become AGILE... to SURVIVE and THRIVE!"
                                                      > http://www.mayford.ca <http://www.mayford.ca>
                                                      > http://practicalagility.blogspot.com
                                                      > <http://practicalagility.blogspot.com>
                                                      > Twitter: daverooneyca
                                                      >
                                                      > Jon Kern wrote:
                                                      > > yeah, i saw balsamiq when i was perusing plug-ins for the wiki/issue
                                                      > > tracker i use (confluence & jira) and it did look way cool.
                                                      > >
                                                      > > Are you using desktop, or a plug-in?
                                                      > >
                                                      > > jon
                                                      > > blog: http://technicaldebt.com <http://technicaldebt.com>
                                                      > > profile: http://www.linkedin.com/in/jonkern
                                                      > <http://www.linkedin.com/in/jonkern>
                                                      > >
                                                      > >
                                                      > >
                                                      > > Dave Rooney said the following on 1/7/09 7:54 AM:
                                                      > >
                                                      > >> Yeah, I believe I'm going to have to get past *my* issues and just do
                                                      > >> it. I had thought about switching from view to edit, but again my
                                                      > >> inherent laziness was kicking in.
                                                      > >>
                                                      > >> BTW, I've started using a tool called Balsamiq Mockups
                                                      > >> (http://www.balsamiq.com/products/mockups
                                                      > <http://www.balsamiq.com/products/mockups>
                                                      > >> <http://www.balsamiq.com/products/mockups
                                                      > <http://www.balsamiq.com/products/mockups>>) for sketching UI's. It's way
                                                      > >> cool - very easy to use and retains that "sketch" look and feel.
                                                      > >>
                                                      > >> Thanks all for the input. It may not necessarily what I wanted to hear,
                                                      > >> but probably what I needed! :)
                                                      > >>
                                                      > >> --
                                                      > >>
                                                      > >> Dave Rooney
                                                      > >> Mayford Technologies
                                                      > >> "Helping you become AGILE... to SURVIVE and THRIVE!"
                                                      > >> http://www.mayford.ca <http://www.mayford.ca>
                                                      > <http://www.mayford.ca <http://www.mayford.ca>>
                                                      > >> http://practicalagility.blogspot.com
                                                      > <http://practicalagility.blogspot.com>
                                                      > >> <http://practicalagility.blogspot.com
                                                      > <http://practicalagility.blogspot.com>>
                                                      > >> Twitter: daverooneyca
                                                      > >>
                                                      > >> William Pietri wrote:
                                                      > >>
                                                      > >>> Jon Kern wrote:
                                                      > >>>
                                                      > >>>
                                                      > >>>> I have found that users really enjoy inline editing on their
                                                      > webpages.
                                                      > >>>> Or at least a simple transition between going from the "view" of the
                                                      > >>>> page to being able to "edit" the page. While sometimes entry of the
                                                      > >>>>
                                                      > >> data
                                                      > >>
                                                      > >>>> (e.g., an image requires browse/upload) is different than the display
                                                      > >>>> (just the image or a thumbnail), users seem to prefer "in-line
                                                      > >>>>
                                                      > >> editing"
                                                      > >>
                                                      > >>>> over going to some other admin-like page to control content.
                                                      > >>>>
                                                      > >>>> I think the basic reason is -- like in document authoring -- when you
                                                      > >>>> see a page that needs editing, it makes sense to edit it right
                                                      > >>>>
                                                      > >> where you
                                                      > >>
                                                      > >>>> are versus going off to some other unrelated place.
                                                      > >>>>
                                                      > >>>>
                                                      > >>> When you describe it that way, that makes a lot of sense.
                                                      > >>>
                                                      > >>> I think Flickr was the first site I saw to get that really right for
                                                      > >>>
                                                      > >> me.
                                                      > >>
                                                      > >>> If you want to edit a photo title or description, you just click
                                                      > on it,
                                                      > >>> and it does some AJAX magic to make the field editable. (As long
                                                      > as you
                                                      > >>> have access, that is.) There's no need to figure out which
                                                      > >>>
                                                      > >> affordance to
                                                      > >>
                                                      > >>> click on, what the right menu choice is, or what tab to go to. It was
                                                      > >>> such a superior interaction that my opinion on JavaScript changed 180
                                                      > >>> degrees in an instant.
                                                      > >>>
                                                      > >>> And from the development perspective, that can sometimes be easier
                                                      > than
                                                      > >>> a separate interface, especially one where you can edit a bunch of
                                                      > >>> things before submitting. If the user's only editing one element at a
                                                      > >>> time as they work inline, then although you have to handle a bunch of
                                                      > >>> different editing operations, they're all clear and sequential, rather
                                                      > >>> than complex and interdependent.
                                                      > >>>
                                                      > >>> If I were you, Dave, I'd try sketching a few different possibilities,
                                                      > >>> perhaps as part of a joint design session with the users. And yes, I'd
                                                      > >>> agree that a spike beforehand might be helpful. Then you can go
                                                      > off and
                                                      > >>> estimate each set of options. If nothing else, this will let you have
                                                      > >>> new and interesting disagreements, rather than one you perhaps
                                                      > have had
                                                      > >>> your fill of.
                                                      > >>>
                                                      > >>>
                                                      > >>
                                                      > >>
                                                      > >
                                                      > > ------------------------------------
                                                      > >
                                                      > > Yahoo! Groups Links
                                                      > >
                                                      > >
                                                      > >
                                                      > >
                                                      > >
                                                      > >
                                                      > >
                                                      >
                                                      >
                                                    • Hassan Schroeder
                                                      ... A free alternative is Denim though it pretty much requires an input device like a Wacom tablet. FWIW, -- Hassan
                                                      Message 26 of 27 , Jan 7, 2009
                                                      • 0 Attachment
                                                        On Wed, Jan 7, 2009 at 4:54 AM, Dave Rooney <dave.rooney@...> wrote:

                                                        > BTW, I've started using a tool called Balsamiq Mockups
                                                        > (http://www.balsamiq.com/products/mockups) for sketching UI's. It's way
                                                        > cool - very easy to use and retains that "sketch" look and feel.

                                                        A free alternative is Denim <http://dub.washington.edu:2007/denim/>
                                                        though it pretty much requires an input device like a Wacom tablet.

                                                        FWIW,
                                                        --
                                                        Hassan Schroeder ------------------------ hassan.schroeder@...
                                                      • James Page
                                                        ... You can use a bit of javascript and regular expressions to do it in the browser. Give the user feedback as they enter the data. Look at some of the
                                                        Message 27 of 27 , Jan 7, 2009
                                                        • 0 Attachment
                                                          There must be some kind of web2.0-y way of providing ongoing feedback as
                                                          to whether the cell contents are valid. Has anyone seen any examples of
                                                          this type of inline cell validation anywhere?

                                                          You can use a bit of javascript and regular expressions to do it in the browser. Give the user feedback as they enter the data. Look at some of the password strength form items in some sign up forms.

                                                          Validation of dates can be done via a pop up calender.

                                                          James
                                                           

                                                          2009/1/7 fitzgeraldsteele <fitzgeraldsteele@...>

                                                          I thought Faith gave excellent advice...empathy is a key tool in user
                                                          experience evaluation.

                                                          So it appears the group is, in general, in favor of inline editing where
                                                          possible. I'm thinking about Excel's cell validation functionality,
                                                          which doesn't have the best experience in my mind. You can define rules
                                                          for a cell, but the rules only get validated when you're done editing
                                                          the cell. And, you get an ugly modal error message.

                                                          There must be some kind of web2.0-y way of providing ongoing feedback as
                                                          to whether the cell contents are valid. Has anyone seen any examples of
                                                          this type of inline cell validation anywhere?

                                                          Someone mentioned Flickr...but that's mostly unvalidated text data.

                                                          The closest thing I can think of is http://www.mint.com, an online
                                                          personal finance site. It gives a standard table view of your
                                                          transactions. When you click on a row, the fields turn editable.
                                                          Additional information that might otherwise appear on a separate edit
                                                          page is instead provided in context in a layer that appears under the
                                                          cell. That might be a model you could use.

                                                          Any others?

                                                          Also, check out the jQuery Validation Plugin.
                                                          http://bassistance.de/jquery-plugins/jquery-plugin-validation/

                                                          This has been an interesting discussion...thanks everyone!

                                                          --- In agile-usability@yahoogroups.com, William Pietri <william@...>
                                                          wrote:


                                                          >
                                                          > Jon Kern wrote:
                                                          > > I have found that users really enjoy inline editing on their
                                                          webpages.
                                                          > > Or at least a simple transition between going from the "view" of the
                                                          > > page to being able to "edit" the page. While sometimes entry of the
                                                          data
                                                          > > (e.g., an image requires browse/upload) is different than the
                                                          display
                                                          > > (just the image or a thumbnail), users seem to prefer "in-line
                                                          editing"
                                                          > > over going to some other admin-like page to control content.
                                                          > >
                                                          > > I think the basic reason is -- like in document authoring -- when
                                                          you
                                                          > > see a page that needs editing, it makes sense to edit it right where
                                                          you
                                                          > > are versus going off to some other unrelated place.
                                                          >
                                                          >
                                                          > When you describe it that way, that makes a lot of sense.
                                                          >
                                                          > I think Flickr was the first site I saw to get that really right for
                                                          me.
                                                          > If you want to edit a photo title or description, you just click on
                                                          it,
                                                          > and it does some AJAX magic to make the field editable. (As long as
                                                          you
                                                          > have access, that is.) There's no need to figure out which affordance
                                                          to
                                                          > click on, what the right menu choice is, or what tab to go to. It was
                                                          > such a superior interaction that my opinion on JavaScript changed 180
                                                          > degrees in an instant.
                                                          >
                                                          > And from the development perspective, that can sometimes be easier
                                                          than
                                                          > a separate interface, especially one where you can edit a bunch of
                                                          > things before submitting. If the user's only editing one element at a
                                                          > time as they work inline, then although you have to handle a bunch of
                                                          > different editing operations, they're all clear and sequential, rather
                                                          > than complex and interdependent.
                                                          >
                                                          > If I were you, Dave, I'd try sketching a few different possibilities,
                                                          > perhaps as part of a joint design session with the users. And yes, I'd
                                                          > agree that a spike beforehand might be helpful. Then you can go off
                                                          and
                                                          > estimate each set of options. If nothing else, this will let you have
                                                          > new and interesting disagreements, rather than one you perhaps have
                                                          had
                                                          > your fill of.
                                                          >
                                                          > William
                                                          >


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