Grouper Developers Forum

["caleb racey" <>]

>Although our timeline doesn't permit us to immediately address the UI
 >issues we've seen in the out of the box UI, Brown is strongly, if not
 >adamantly in favor of working within the current struts/skins
framework
 >to develop a more end user friendly UI. We adopted Grouper because of
 >its Java framework, and we've become familiar with its architecture.
To
 >switch architecture at this point would be counterproductive. As Tom
 >points out, the out of the box UI is acceptable to demonstrate
 >capabilities for power users, but each campus may have its own UI
needs.
 >Chances are, many campuses will have similar needs, so I suspect a
 >collaborative UI design review will be very useful for all interested
 >campuses.
 >

Newcastle's position on UI review would be similar. We are in favour of
keeping a java/struts approach, however we are open to alternatives if
necessary

Having tried to understand the default UI in order to make campus
specific changes I found it hard to deal with. Making even a simple
change to the ui took more than 3 hours to achieve. The learning curve
for working with the  ui is steep, you have to understand 
1) ant build + deployment process 
2) struts (even finding which file is behind a url is non trivial)
3) interaction with   grouper api
4) the source adapter 
Before you can even begin. 
  
This is not desirable as the ui is the first point that many sites will
want to customise.    However despite this I feel a java/struts based
approach is still desirable, we have an existing  java infrastructure
and we are encountering more and more struts based applications. Struts
seems to be the preferred web framework in the wider community.
Therefore an investment of time in gaining struts skills for grouper
work would have additional benefits for us.   

One area which may be useful for ui work would be to put some kind of
simple webservices api on top of the grouper api. With a webservices
exposed api  we could write quick and dirty apps in any programming
language (e.g. php) that interact with grouper to add group members etc.
This would be enable us to quickly and simply integrate desirable for
apps like blogs, wikis with grouper.    

Regards
Cal

Caleb Racey
Webteam
ISS
Newcastle University
U.K.

 


  



 >James Cramton
 >Lead Programmer/Analyst
 >Brown University
 >
 >401 863-7324
 >
 >
 >-----Original Message-----
 >From: Tom Barton 
 >[mailto:]
 >Sent: Thursday, August 30, 2007 1:59 PM
 >To: Cramton, James
 >Cc: Grouper Dev
 >Subject: Re: [grouper-dev] Grouper 1.2.0 in production at Brown
 >
 >Thanks very much for this overview of where things now stand with
 >Brown's deployment!
 >
 >Cramton, James wrote:
 >> What we've seen now that we're starting to get some real data is
that
 >> any future interface design for MACE Grouper needs to take common
use
 >> cases, configurability, and ACLs very seriously. For example, ...
 >
 >> I know there is talk of a project to review the UI requirements.
Where
 >
 >> does that stand these days?
 >>
 >> Over the next week, I will be documenting the issues we're having in
 >> JIRA, complete with screen shots and analysis.
 >
 >Excellent. This type of data and feedback should help us to identify
 >specific improvements needed for the UI.
 >
 >More fundamentally, the as-shipped UI demonstrates just about *all* of
 >the underlying API capabilities, and without modification it's
suitable
 >only for power users. Now several campuses are at or very near the
point
 >at which they'd like to provide a simpler UI to a broader usership.
The
 >question is how should one be produced? There are two main options:
 >develop a second, ordinary-human usable "skin" on top of the existing
UI
 >infrastructure (through changes to properties, struts config, and a
 >little custom jsp), or develop a wholly new UI application.
 >
 >I'd really like to convince someone to look into the first option (new
 >skin for existing UI), as it seems likely to be the quickest and
 >cheapest way to produce a more usable UI. And developing a wholly new
UI
 >  may have to proceed without any corresponding funding, making it a
 >higher hurdle.
 >
 >>     20 min: Provision LDAP from MACE Grouper using LDAPpc
 >
 >The fixes in v1.2.1, plus a one or maybe two line patch to ldappc to
 >take advantage of one of them, ought to net a substantial performance
 >improvement in ldappc. Might you be willing to benchmark it?
 >
 >
 >Tom