Software written for commercial purposes, in fact, tends always to have a slew of different settings that can be manipulated by the end user. The premise would seem to be that the developer knows not what the user wants specifically but has only a general idea. As I embarked on this project, I took what I had learned in software engineering courses that teach you to gather requirements, adapt to changes, and meet frequently with the customer as part of the software development lifecycle (SDLC) and applied it to my approach. In all of this, the goal was validation. Are we building the right software? Is this what the customer wants?
One would imagine after the process geared toward constant/frequent validation was over we'd have tailored the system enough to exactly meet the customer's wishes. Why then, should I deem it necessary to include lots of settings?
Settings are a means to adapt to change even after the project is over. One of the settings I included in the project, for instance, was the URL of the client's webpage. Should this ever change in the future when I'm no longer working with the client, they should be able to make the adjustment for themselves, rather than hire a new developer. (Part of the system I built was a lite web browser that kept users within the domain of the client's website).
Settings satisfy a clientele who changes their mind often. I needed to include a setting for the length of time of inactivity on the software to return it to a default view. The client initially thought that 2 minutes was the appropriate length. He eventually changed it to 5, and then to 10. I said in one of the meetings, "How about I let you decide later in the admin interface?" Not surprisingly, that was perfectly agreeable to both parties.
Settings make the product personal. The application my team and I developed for our client was a kiosk application for a tablet connected to a large Samsung display. One of the settings included was what the default screen would say when no one was walking up and using it. I was initially told exactly what the client wanted it to say on that screen. However, I went ahead and included this as an option to be set by the admin if in the future he felt differently. A few prototypes down the road, our client was taking a swing at using it by himself without our guidance and one of the first things he did was take that title and make it his own.
My advice is, giving the end users options shouldn't be optional. Do it. Make the application as customizable as you can as long as it can't be changed so that it no longer serves its purpose. If a client is set on one specific "background color" for a GUI, for instance, it means you need to dust off that color chooser control and cram it in there. Chances are, your client will be ultimately more happy with the fact that he or she gets to choose the color any time he or she wishes versus realizing it doesn't quite look so hot anymore a few weeks down the road.
One would imagine after the process geared toward constant/frequent validation was over we'd have tailored the system enough to exactly meet the customer's wishes. Why then, should I deem it necessary to include lots of settings?
Settings are a means to adapt to change even after the project is over. One of the settings I included in the project, for instance, was the URL of the client's webpage. Should this ever change in the future when I'm no longer working with the client, they should be able to make the adjustment for themselves, rather than hire a new developer. (Part of the system I built was a lite web browser that kept users within the domain of the client's website).
Settings satisfy a clientele who changes their mind often. I needed to include a setting for the length of time of inactivity on the software to return it to a default view. The client initially thought that 2 minutes was the appropriate length. He eventually changed it to 5, and then to 10. I said in one of the meetings, "How about I let you decide later in the admin interface?" Not surprisingly, that was perfectly agreeable to both parties.
Settings make the product personal. The application my team and I developed for our client was a kiosk application for a tablet connected to a large Samsung display. One of the settings included was what the default screen would say when no one was walking up and using it. I was initially told exactly what the client wanted it to say on that screen. However, I went ahead and included this as an option to be set by the admin if in the future he felt differently. A few prototypes down the road, our client was taking a swing at using it by himself without our guidance and one of the first things he did was take that title and make it his own.
My advice is, giving the end users options shouldn't be optional. Do it. Make the application as customizable as you can as long as it can't be changed so that it no longer serves its purpose. If a client is set on one specific "background color" for a GUI, for instance, it means you need to dust off that color chooser control and cram it in there. Chances are, your client will be ultimately more happy with the fact that he or she gets to choose the color any time he or she wishes versus realizing it doesn't quite look so hot anymore a few weeks down the road.
No comments:
Post a Comment