Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am in a meeting with a client later on, regarding an ASP.NET web app we are creating for him. The app includes a lot of 'form' style screens with 20-30 textboxes, and of course a 'Save' button that posts back to the server and saves the data.

The client really does not like this as he is worried users will forget to click 'Save' and lose their data.

While I obviously understand that we can use AJAX to save as the user goes along, I believe this is beyond the scope of the project and is prone to error.

Has anyone dealt with clients like this?

share|improve this question

closed as off-topic by gnat, MichaelT, GlenH7, Bart van Ingen Schenau, Kilian Foth Apr 25 at 11:11

  • This question does not appear to be about software development within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

could you please clarify why do you believe that AJAX is prone to error? –  gnat Apr 24 at 8:47
...also, given the mention of scope, do you have an option to make an initial release with the button and later make an update release, possibly without that button? –  gnat Apr 24 at 8:59
Don't forget that the modern paradigm, especially on mobiles, is "what you see is the way it is". We're busy getting rid of Save butttons and finding other ways to backtrack or undo. –  david.pfx Apr 24 at 11:07
This question appears to be off-topic because it is about managing client expectations and is not about a conceptual programming issue. –  GlenH7 Apr 24 at 13:27

4 Answers 4

I were in the same situation recently where the client didn't want to have the Save button, even tho the forms where pretty simple and were all fit into the screen with the Save and Cancel button.

I managed to make a simple form with auto-save feature and conduct a test with couple of their real-world users and the conclusion was more than 30% of times those people change their mind after editing the data -- want to cancel edits, and almost 80% of them didn't notice in the beginning that it is an Auto-save form.

So the main arguments here are:

  • You need an Undo feature, because people might change their mind or edit the wrong filed, etc.

  • You need a Cancel All Edits feature, for the same reason as above -- imagine if you have changed the profile data of another client and you realize it after you have edited couple of fields.

The final solution that we came up with was:

  • To have a small notification when anything saved on the server,
  • And an Undo button next to the notification,
  • Plus a Cancel Edits button which resets all the edits and loads the fresh version -- before any edits, however this is available only if you don't finish and leave the page. After that data is permanently updated and you won't be able to rollback at all.

As it was a Node.js app, I used Socket.io, but that's perfectly possible with Ajax as well. Also for the Cancel Edits I just simply kept a copy of form data in JSON format, so it's kind of a hard-copy of the form-data that won't be edited at all, so anytime the user changes their mind, they can simply rollback to the fresh data that were initially loaded into the form. As I said again, you will lose this data after you leave that form.

share|improve this answer

Why do you assume you're right and your customer is wrong?

  • Either you have enough knowledge in UX field; in this case, it won't be difficult for you to find the reason why, in the particular case of the app you're working on, having a Save button is a must-have, and how to explain that in non-technical terms to the customer.

    For example, you may be in a case where the end user don't want his changes to be seen immediately online, and it can make sense to spend a good amount of time changing the content before pushing the Save button. It's exactly what happens right now: I'm editing my answer, and I while it's possible technically to make the changes visible to everyone in real-time (through WebSockets), Stack Exchange let me decide when I consider my answer is finished and should become visible to the public.

  • Or there is a technical constraint making it either difficult, or impossible to implement an AJAX solution. Here again, explain it to the customer, explain the additional cost, and let the person decide.

    For example, adding AJAX to every form at this stage would have an additional cost of $20,000. While you consider that the ROI of this change is particularly low, your customer may have a very different opinion on the subject.

Don't plainly assume customers are wrong, especially if you need to ask on a Q&A website for arguments to support your point of view.

There are cases where customer' mistakes are obvious: in those cases, it may not be easy to find how to explain the error to the customer, but at least the arguments under their technical form are abundant and obvious. As a professional, it's up to you then to guide your customer to a better solution.


Customer: I was reading that in order to avoid issues with Unicode, data should be stored in Base64. Please, can you store everything in the database in Base64?

You: Base64 increases the size of the data with a ratio of 4:3. This means that for every 3 GB of data, you'll actually store waste 4 GB of space. Also, storing the data in this format will make it much more difficult to manipulate the data by hand during the debug and testing phase. Finally, I'm using Microsoft SQL Server and a C# application; both have a good support for Unicode. I also worked on this project and that one which used Unicode extensively, so I know pretty well how to handle Unicode and avoid the usual pitfalls.

There are also cases where your opinion differ from customer's one, and none is right or wrong. In such case, remember that:

  • Customer has the last word on the requirements.

  • You have the last word on the price.


Customer: Great. Finally, I want it to be done in PHP.

You: Frankly, I don't enjoy PHP too much. Ruby or Python can do the job too, and your server is fully compatible with both.

Customer: I know. But I still prefer you do it in PHP.

You: Is it because you have somebody in your company who knows PHP better?

Customer: No. But several programmers I know told me PHP is great.

You: Ok. But since I program mostly with Ruby and haven't used PHP for the last four years, I'll have to spend some time relearning stuff, and I would be a bit slower than if I were coding in Ruby. Is it ok for you to increase the cost of the project from $25,000 to $28,500, and move the deadline from August 10th to September 10th?

share|improve this answer

This is a priorities thing.

There are two competing priorities.

  1. Users losing their data, and either having to retype everything, or becoming frustrated and aborting the process. This is potentially a CRITICAL ISSUE in a sales app, because "aborting the process" in this case means not paying the client.
  2. Errors creeping in due to saving unwanted data, and costs associated with server load. This may or may not be a critical issue, depending on the robustness of the system, the amount of load involved and the amount of money being thrown around. (I would note that a Save button in no way protects you from either of these issues, as people generally save incorrect information and if you lose their data and they re-start, that's also server load)

The weight you give to these priorities is up to the client. If they simply don't realise that your solution will solve their problem to their satisfaction, it is your job to demonstrate to them that it will. If your solution treats their concern as "not a real problem", then you have misunderstood your job. Your job is to solve their their real-world problem ("Somebody has to supply us with 30 different items of data, and they'll throw their computer out the window if they fill in 29 items and then it gets lost when their browser crashes. And more importantly, they won't buy from us.") Unless you solve that problem, you're not doing your job.

The key thing to do here is prototype. If your preferred solution is easy to prototype, you prototype it and you can either show the client how you solve their issue, or they can show you how your solution doesn't solve their issue. If it isn't, you are "preferring" a solution that is difficult to code and doesn't necessarily do what the client wants. Don't prefer that, it is not preferable.

share|improve this answer

In this day and age of Google Docs auto-updating the server with data as you type, I don't think its unreasonable to have 30 textboxes being written to the server periodically (or even every time the user changes focus from one to another).

You could use ajax, but my preferred solution would be to open a websocket to the server and just send the relevant textbox data everytime the user enters text in one.

In dealing with the client - its not beyond the scope of the project as this is part of his requirements, hence it is in scope. Be glad you have a progressive-thinking client who wants to enhance the capabilities of web interaction like this and embrace the challenge.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.