Generic/Adoptive User Interface Design

[Stewart Rogers]

Hi all,

I have been working on an ASP.NET application that is a kind of wizard ( a
list of sequential pages ). We built that application for the CLIENT-A and it
worked fine. After six months CLIENT-B came along and and requested the same
application but with little bit different requirements (both in terms of the
front-end and back-end processing), so we had to create a new application for
that client. Now came CLIENT-C !!!!!!

I am not into the favor of creating one more application for this client and
have been thinking about creating one generic application that will fit most
of our clients needs; I mean the application has to change the behavior based
on the client for which it has been called.

For example, CLIENT-A requires all pages to be shown in a sequence (Page1,
Page2, Page3, Last Page). CLIENT-B does not want to show Page1, rather they
want to show Page2, and the Last Page. CLIENT-C wants to show all of the
pages in the same sequence but has less data entry fields on some of the
forms!!!

Now is there a way I can implement/architect/design a generic/semi-generic
application that would change its behavior based on the client for which it
has been invoked for? any design pattern that would do the trick for this
kind of application? any insights?

Thanks in advance.

Stewart

[rmgalante]

If your clients login, you can use the client id associated with their
userids to read a database table that defines the names of the pages
that you will redirect to. It's not very difficult to do actually. I
use this technique all the time with Intranet applications where the
users login in, and based on their roles, I display menus with lists of
pages that they can access. All pages verify that the user's role is
valid for that page, and if not bounce the user back to the login page.

So, in its simplest form, you need a database table for the users and
passwords, a table that links userids to client companies, and a table
that links client companies with pages. Then use a session variable or
a viewstate variable to pass the client id from page to page after the
client logs in.

[Stewart Rogers]

Thanks for sharing your experience.

I do understand that and I was thinking along that direction but my
requirements are just not that simple! I know I can walk user through a bunch
of pages driven from a database table but there is more to it. Such as:

(1) Pages may have different data entry fields for each client
(2) Pages may have different data validation rules for fields for each
client (first name should be at most 50 characters for CLIENT-A but should be
40 characters for CLIENT-B, etc).
(3) Pages may have to do some "pre" and "post" processing that might be
specific for each client (For example, CLIENT-A wants Page1 to come up with
empty fields, whereas CLIENT-B wants Page1 to talk to client's web service to
fetch data and fill the fields, etc)
(4) and ofcourse user interface images and asthetic changes for each client!

that is the kind of app I am talking about here.

Any help guys?

thanks,
Stewart

"rm*******@yaho o.com" wrote:

If your clients login, you can use the client id associated with their
userids to read a database table that defines the names of the pages
that you will redirect to. It's not very difficult to do actually. I
use this technique all the time with Intranet applications where the
users login in, and based on their roles, I display menus with lists of
pages that they can access. All pages verify that the user's role is
valid for that page, and if not bounce the user back to the login page.

So, in its simplest form, you need a database table for the users and
passwords, a table that links userids to client companies, and a table
that links client companies with pages. Then use a session variable or
a viewstate variable to pass the client id from page to page after the
client logs in.