8 Replies Latest reply: Mar 5, 2013 4:43 AM by Koen Verhulst RSS

    ADF 11g: autosave functionality

    Koen Verhulst
      All,

      For my current project, I'm investigating the possibility to add autosave functionality to an (new) application. Is there perhaps anybody on the JDeveloper and ADF forum who already tried to implement such a functionality?
      (JDeveloper 11.1.2.3.0 - ADF BC - ADF Faces Rich)

      First question that rise up:
      1) How to handle validation on the page?
      2) Is it intended/needed to change the database tables design? (eg: less required field)
      3) How/when to trigger a save call?
      4) How to handle errors?

      For the record: are there any plans on integrating autosave functionality to futuristic versions?

      Thanks in advance,

      Koen Verhulst
        • 1. Re: ADF 11g: autosave functionality
          Frank Nimphius-Oracle
          Koen,

          I think that 1 - 4 are not related to autosave as a functionality. What you really want to do is to implement a solution that behaves like a user clicking onto commit every 5 minutes. So for this you can use af:poll to then issue a request to a managed bean that looks up a submit button on a page to queue its event. This then behaves like any other zser save action. I don't understand the use case for why e.g. you think auto save should be allowed to save invalid data +"(eg: less required field)"+ . What I think though you really want is "save as draft" which is completely different use case as it saves a copy of the data for temporary use. So for the records: the latter is not planned as a native framework feature and the first case can be implemented as explained above.

          Frank
          • 2. Re: ADF 11g: autosave functionality
            Koen Verhulst
            Hi Frank,

            first of all: thanks for your reply.

            I probably did not express myself very well. With "autosave", I also mean the functionality where a form get saved "automatically" whenever a user tabs/clicks out of an inputfield. We are currently having a discussion where we are reviewing whether this could improve the user experience (or not). For example: an edit screen of an employee where the complete form gets saved as soon as a user changes a certain inputfield. The bugtracking tool we are currently working with, works in such a way. As soon as we edit a field of a certain issue, the issue get asynchronously saved to the database. We were discussing whether this could/would impact our way of designing the database, since it would be quite annoying error/validation messages poping up whenever we tab/click out of an editable component.

            Although I'm "assigned" to investigate the possibilities in this field, I dont believe this is the way to go because I prefer to keep data as valid as possible in the database.
            (According to a team member, this is the way to go. And I quote: "this is the key feature of web applications".)

            Kind regards,

            Koen Verhulst
            • 3. Re: ADF 11g: autosave functionality
              Timo Hahn
              Koen,
              for me this would be a bad design. Autosave has to be considered carefully. Storing invalid data in the db is a no-go from my point of view. I never heard of a statment like
              According to a team member, this is the way to go. And I quote: "this is the key feature of web applications".
              From a users perspective a design with autosave on leaving an inputfield is not desirable too.
              User enters wrong data in to a field leaves the field and don't get an error? This sounds strange. When would you do the validation? Never?
              What about use cases where you can't validate the input directly because the validation has to include some other fields which are not filled jet?
              In the end you are programming this for each form for specific input fields. This doesn't sound like something I would want to do.

              If your use case is like: I don't want to loose any data which is entered, no matter if it's valid or not, then you can go another way. Implement some kind of serialization of the form and store the serialized data into a blob whenever a field looses focus.

              Timo
              • 4. Re: ADF 11g: autosave functionality
                Koen Verhulst
                Hi Timo,

                thanks for your reply.

                The quote was about the fact that "an (auto) save functionality whenever leaving the field" will become a "key" feature in web applications. I dont think it will go that far, but I notice that more and more applications on the web are handling some kind of "automatic" save functionality, whether it is saved as a draft or not, there is an "automatic" save (eg: gmail,jira,...). According to me it is not appropriate to introduce automatic save (as in: as soon as a user leaves a field it will be saved. Will call it just automatic save from now on) in web application handling with complex data, because (complex) validation will probably needed. But I do think it can be handy in some scenarios where users are just editing simple records. On the other hand I dont think its a good idea to mix implicit and explicit saves.

                The primary reason to implement such a functionality is more about enriching the user interface and less about making sure the data dont get lost (although this is a reason too).
                By the way: take a look at an iphone (or mac in general) for example as soon as you change a setting, things get stored, there is no need to press a save button.

                Nice to read:
                http://ux.stackexchange.com/questions/2754/autosave-ui-pattern

                Kind regards,

                Koen Verhulst
                • 5. Re: ADF 11g: autosave functionality
                  Frank Nimphius-Oracle
                  the link you posted, isn't it contradicting to your team member's suggestion

                  +(According to a team member, this is the way to go. And I quote: "this is the key feature of web applications".)+

                  Anyway. The use case should be implemented in a save as draft manner. Any record, until explicitly saved will be kept as a draft. You can add autosubmit=true to all input fields so that changes are applied to the model. Using a value change event you can also commit the changes entered by a user. Once the user is happy or a specific condition is met you take the draft row and copy it to the production table. Here your user experience will drop massively if validation fails because the user did not know that what he/she typed in didn't meet the required data consistency policy. If you look at the auto-save functionality of email client, they do similar. However, they don't claim its for better usability but for protecting against loss of drafted mail content.

                  If you ask me the before solving this issue technically you should have a word with the team member about what the expected usability gain should be and how he/she feels about required data validation. Note that there is no such thing than "less required validation". Either you have a requirement for data consistency (and this is where you put validation in for) or you don't.

                  Just my 2 cents. Get the requirements sorted and the technical solution almost shows itself

                  Frank
                  • 6. Re: ADF 11g: autosave functionality
                    Timo Hahn
                    By the way: take a look at an iphone (or mac in general) for example as soon as you change a setting, things get stored, there is no need to press a save button.
                    That is what I mean. I change multiple fields and they get saved, then I decide that the changes are not what I want to do (may be because I 'm not sure how they influnece the app). How do I get back to the original values, if I changes so many I can't remebmer them all?

                    If you look at gmail, this works like the use case I outlined in my other post. Store the data as is so that they don't get lost. I've implemented this use case for complex entry forms with multiple tabs where validation (of all entries) is done when the user clicks save. As filling out all the fields on hte multiple tabs is time consuming and can even take day if some information is missing, we store the data in a blob. So the use can come back later and see all data.

                    This however is more like Franks suggestion...

                    Timo
                    • 7. Re: ADF 11g: autosave functionality
                      Koen Verhulst
                      Hi Frank, thanks for your reply.
                      the link you posted, isn't it contradicting to your team member's suggestion
                      Yes, it is. I'm just searching for the right arguments pro and contra a autosave functionality. I dont think one can state that "autosave functionality enrich user experience".
                      ... Here your user experience will drop massively if validation fails because the user did not know that what he/she typed in didn't meet the required data consistency policy
                      It is not intended that a user does not know where something went wrong. Even after a "autosave" messages should inform the user whether the save is valid or invalid and if validation failes he should be informed where and why it went wrong.
                      ... you should have a word with the team member about what the expected usability gain should be and how he/she feels about required data validation.
                      The team member believes:
                      - applications would work better on tablets.
                      - it would be better for overall user experience.
                      - give an end user more freedom.
                      - there should be less required data.

                      My personal opinion is that I want to decide myself whenever I want to save a form and I dont want invalid data in the database. I'm just trying to see web applications from inside an end-users head and I'm not - like you guys - convinced that this is a kind of functionality that users are waiting for.

                      Koen
                      • 8. Re: ADF 11g: autosave functionality
                        Koen Verhulst
                        Hi Timo,

                        thanks for your reply.
                        That is what I mean. I change multiple fields and they get saved, then I decide that the changes are not what I want to do (may be because I 'm not sure how they influnece the app). How do I get back to the original values, if I changes so many I can't remebmer them all?
                        I agree. But this is also the case on iphone/mac. I never had the feeling that I missed the functionality to restore orginal value on mac/iphone.
                        If you look at gmail, this works like the use case I outlined in my other post. Store the data as is so that they don't get lost. I've implemented this use case for complex entry forms with multiple tabs where validation (of all entries) is done when the user clicks save. As filling out all the fields on hte multiple tabs is time consuming and can even take day if some information is missing, we store the data in a blob. So the use can come back later and see all data.
                        The reason you stored your data in the blob, is because you want to keep all validation in the entities, right? And validation should only occur when the data is - according to the user - filled in completely?

                        Regards,

                        Koen Verhulst