It has been a long time since I sat down and designed the UI for a consumer facing web site. The last few years I'd been working on the UI elements for the management interfaces of the distributed framework that powers the consumer collaboration site. Now that I am head deep in the task of writing feature lists, designing comparison tables and writing description pages for the various pages that are important for a consumer site I remember just how boring it can be! Tons of boring pop corn, tons of basic html but much of it repetive save for a few minor changes which must be done manually (especially when doing comparision tables) argh!
Good to know that I am almost done, but I was able to make several choices in the design of the site that might be instructive to those working on or soon to be working on a similar project. First, a short description of the page and then I'll go over the choices I made to expedite facile management of the content later as the need arises. The site presents the simple options of starting a new account with the service, participating as a guest to the service without starting an account, logging in to the service with an existing account , selecting a preferred language to read the site in and asking a live agent about the service when such an agent is available to converse. Additionally the site presents a standard list of links that specify the options for learning about the services being offered, my list is as so: "home,features,for business,compare,serviceplans,tos,privacy,about us" Pretty basic. A banner section at the top of the page displays the logo and slogan. The content is displayed below the banner for the selected clicked on link option....how to proceed?
I decided straight away to cut up the page into sections that render dynamic content and static content. The main page is a dynamic jsp template that calls in dynamic templates for the links list, the side bar that displays the new account, existing account login and guest service options and one variable call (for some pages static resource others dynamic) to the content corresponding to the displayed link and the banner logo. The reason these are static/dynamic calls to separate files has to do with two things, first is the language options, I want every native speaker to think the entire site was originally written in their language so I am translating even the images to the selected language option. The content of the selected page will of course be translated as well...the best way is to simply pass a parameter to the url for the selected language and dynamically call the static content that is associated with that language. The second reason is that some of the pages "serviceplans" vary their display depending on if a user is logged in, in this case showing a short summary of the logged in Users plan and account status as well as indicating their current plan and providing links to change their plan option.
The dynamic calls are very similar to the static ones in terms of having copies for each language but they have dynamic processing that must be done to determine if a user is logged in or if the viewer is simply a visitor. There is also logic to determine if a live agent is available to help with questions a visitor may have in real time chat, finally there is logic to allow a real time count of the number of participants in the service at the time the visitor is viewing the page. Though it took a bit longer to set up this structure, it will now be trivial for me to a) add new languages to the site and b) change in particular language content for each link page independently. It is a perfect example of how taking the time to properly design something leads to more efficiency in the long term. Now that I am getting out of the Briar patch of html popcorn I am starting to see the usefulness of the modular design, for example, I needed to provide the links on a new Users management interface after they've logged in, since the links were generated in a dynamic resource varied by language, I simply included it in the management interface pages and provided the Users language parameter to render the correct template and voila. No need to duplicate any code. Object orientation rules the day. I hope to start the logic to enable service plan options after receiving confirmation from the payment processor by mid week...getting to the end of the road, slowly but surely, just have a bit more popcorn to munch before I get there!
Good to know that I am almost done, but I was able to make several choices in the design of the site that might be instructive to those working on or soon to be working on a similar project. First, a short description of the page and then I'll go over the choices I made to expedite facile management of the content later as the need arises. The site presents the simple options of starting a new account with the service, participating as a guest to the service without starting an account, logging in to the service with an existing account , selecting a preferred language to read the site in and asking a live agent about the service when such an agent is available to converse. Additionally the site presents a standard list of links that specify the options for learning about the services being offered, my list is as so: "home,features,for business,compare,serviceplans,tos,privacy,about us" Pretty basic. A banner section at the top of the page displays the logo and slogan. The content is displayed below the banner for the selected clicked on link option....how to proceed?
I decided straight away to cut up the page into sections that render dynamic content and static content. The main page is a dynamic jsp template that calls in dynamic templates for the links list, the side bar that displays the new account, existing account login and guest service options and one variable call (for some pages static resource others dynamic) to the content corresponding to the displayed link and the banner logo. The reason these are static/dynamic calls to separate files has to do with two things, first is the language options, I want every native speaker to think the entire site was originally written in their language so I am translating even the images to the selected language option. The content of the selected page will of course be translated as well...the best way is to simply pass a parameter to the url for the selected language and dynamically call the static content that is associated with that language. The second reason is that some of the pages "serviceplans" vary their display depending on if a user is logged in, in this case showing a short summary of the logged in Users plan and account status as well as indicating their current plan and providing links to change their plan option.
The dynamic calls are very similar to the static ones in terms of having copies for each language but they have dynamic processing that must be done to determine if a user is logged in or if the viewer is simply a visitor. There is also logic to determine if a live agent is available to help with questions a visitor may have in real time chat, finally there is logic to allow a real time count of the number of participants in the service at the time the visitor is viewing the page. Though it took a bit longer to set up this structure, it will now be trivial for me to a) add new languages to the site and b) change in particular language content for each link page independently. It is a perfect example of how taking the time to properly design something leads to more efficiency in the long term. Now that I am getting out of the Briar patch of html popcorn I am starting to see the usefulness of the modular design, for example, I needed to provide the links on a new Users management interface after they've logged in, since the links were generated in a dynamic resource varied by language, I simply included it in the management interface pages and provided the Users language parameter to render the correct template and voila. No need to duplicate any code. Object orientation rules the day. I hope to start the logic to enable service plan options after receiving confirmation from the payment processor by mid week...getting to the end of the road, slowly but surely, just have a bit more popcorn to munch before I get there!
Comments