Dave Odom wrote:
I'm not addressing requirements for a small user group,
its the entire user community of the i5.
Okay. In that context, talking about architecture makes sense. And that could
lead to portals.
I'm presently in the process of updating the navigational aspects of a portal,
and talking about it might illustrate some of the constraints I referred to in
an earlier post about Microsoft's UI component approach to Web applications.
The top-level navigational element in my portal is called a Work Area. In the
event that you're hosting data for multiple clients on a single server, Work
Areas are a handy means of separating client data into separate libraries, and
allowing users to select a particular client Work Area prior to launching or
accessing a Web application, where the application would use the library list
for that particular client, for example.
The next-level navigational element is a Menu. Menus may contain links to
Sub-menus as well as links to Applications.
I use a horizontal navigational bar which shows the hierarchical path the user
has traversed to access an application, and the navigational bar is always
visible, no matter how many applications the user may be using concurrently. A
task bar also always visible, and with a single click, it enables users to swap
between multiple applications running concurrently.
The challenge is to provide a smooth transition as users navigate the Work Area
/ Menu lists and incrementally update the navigational and task bars as users
select Work Areas, Menus, Sub-Menus, and Application links.
If you're a developer, and accustomed to the design palette provided by Visual
Studio for Web Applications, it may not occur to you how to design or develop
the type of navigational elements I've described, or how to incrementally
update the navigational bar and task bars and enable swapping between
concurrently running applications while preserving the state of each as you
swap.
You need to think outside the box, so to speak.
Nathan.
midrange.com
