Most Flexible UI Architecture?

[pbd22]

Hi.

I am in the process of designing a Web site and would like
advice on the best (most flexible) design for the client
interface. What I am primarily interested in is how to
architect the UI so changes can be made with ""very little""
effort moving forward and major redesigns are avoided.
What is the current best practice?

Also, how much advantage/disadvantage is involved when
pumping the client UI (html, etc) via ajax on page load?

Thanks in advance.

 

[Gregory A. Beamer]

Hi.

I am in the process of designing a Web site and would like
advice on the best (most flexible) design for the client
interface. What I am primarily interested in is how to
architect the UI so changes can be made with ""very little""
effort moving forward and major redesigns are avoided.
What is the current best practice?

Also, how much advantage/disadvantage is involved when
pumping the client UI (html, etc) via ajax on page load?

Thanks in advance.

The most flexible is to move the application code into libraries and use
the user interface as a faceplpate for user entry. If you go this
direction, you can fairly easily go from ASP.NET to add AJAX to ASP.NET
MVC, etc.

As for AJAX, the pumping with AJAX is a bit overrated in my opinion, but it
does give you one common way of getting the data. I find jQuery a bit
easier to use and it can load a bit more dynamically.

 

[pbd22]

The most flexible is to move the application code into libraries and use
the user interface as a faceplpate for user entry. If you go this
direction, you can fairly easily go from ASP.NET to add AJAX to ASP.NET
MVC, etc.

As for AJAX, the pumping with AJAX is a bit overrated in my opinion, but it
does give you one common way of getting the data. I find jQuery a bit
easier to use and it can load a bit more dynamically.

Hi Gregory,

Thanks for the response.

I have been using DLLs in my project, but entirely for server-side
stuff.
Now that I am thinking hard about UI design, I am wondering how to
design
it so removing a widget here or there does not require a major
redesign down
the road. I am ashamed to admit that, in the past, the way I designed
the client interface was simply writing the HTML on the aspx page. So,
the
HTML is basically hard coded and, when data is needed, I used a server
tag (or ajax) to get it. This approach is messy because, what if I
want to change some UI items? Its all hard-coded.

I am assuming by your DLL suggestion you r saying that the DLL should
be
scripting all of the HTML from the server? When you do this, do you
script "all"
of the page's HTML from the server? Is this normal? I can see how this
would be easier as an update to a DLL isn't all that involved.

Thanks again.

 

[Gregory A. Beamer]

I am assuming by your DLL suggestion you r saying that the DLL should
be
scripting all of the HTML from the server? When you do this, do you
script "all"
of the page's HTML from the server? Is this normal? I can see how this
would be easier as an update to a DLL isn't all that involved.

Thanks again.

here is how I design things, to add some clarity.

1. Set up tests for the functionality (generally from use cases)
2. Create the functionality in libraries.
3. Test

you can swap steps 1 & 2 if you are using a test after approach rather
than test driven. It is easier with VS 2008 Pro (or greater) or VS 2005
Team (Architect, Developer, Test or Suite) as ther eis no proper TDD
approach in either of these ("fixed" in VS 2010). You can also use
another framework (nUnit, for example) for the TDD approach in VS 2008
or earlier, if you want to have your tests drive designs.

Once test, I add the UI page. It's sole responsibilities are displaying
data for the user and allowing the user to change data and submit back.
The libraries actually do the hard work.

This is an approach Microsoft has advocated for years but,
unfortunately, has not demonstrated very well outside the architecture
group (patterns & practices, et al).

If the logic changes, or I find a bug, I can alter existing changes or
add a new test (depending on change type) with very little impact on the
UI, if any.

One huge benefit is when the client says "can we make this a Silverlight
app", I do not have to rewrite the application, only the UI bits.

Hope this helps!