You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by "J. Wolfgang Kaltz" <ka...@interactivesystems.info> on 2005/03/14 11:47:31 UTC

Re: usecase framework / navigation

Andreas Hartmann schrieb:
>> (...)
>> I am wondering if and how this should transferred to the usecase 
>> framework. Would this be the "View available group-related usecases" 
>> usecase, with isInteractive set to false ?
> 
> 
> Actually I didn't yet think about that. I saw a usecase as a user
> interaction scenario as well, but that can be interpreted in many ways :)
> 
> The implementation of plain views (e.g., the overview screens in the
> admin area) is very simple using usecases. You just have to write
> a little bit of Java to create the model and a JX template to present it.
> 
> I think it's fine with me to use the usecase framework for this purpose.
> 
>> So in essence, the navigation itself would be use-cases ? (at least in 
>> authoring, not sure about live)
> 
> 
> Do you mean the website navigation? Could you explain a bit more?

If I understand correctly, in the site (that is, info-authoring) area, 
navigation is already a usecase. That is, user clicking on site triggers 
the use case "show all available use cases for site, that is, meta, 
assets, versions etc.". This use case is called "tab" (which BTW is not 
a good wording, as it just names the GUI pattern, instead of what it 
achieves). So I suppose that for the "admin" area we want to implement a 
similar overview use-case, which would lead to the various admin use-cases ?

What I am wondering is, how far this idea of using use-cases to 
implement navigation should go. Because if we take the idea of the site 
navigation ("tab" usecase) further, the whole navigation would become 
use cases. That would mean, in the admin/authoring area, after the login 
usecase, the user is presented with the list of possible use cases. How 
it is rendered is a different issue of course. If she chooses the 
use-case "show admin use-cases", she is taken to the next step, i.e. 
shown the available use-cases in admin area.

The same issue holds for the live website navigation. It might be 
helpful to reflect upon website navigation as a usecase as well, I don't 
know. I'm thinking roles, that is which user may see what, and perhaps 
even (for the future) adapting the page to some situation, i.e. which 
parts are shown in which situation. Since some hooks for logic are 
needed anyway when delivering content in the live website, it might make 
sense to think in terms of usecase framework.

In any case, what is not so good at the moment in the 
admin/site/authoring stuff, is that navigation concepts are entirely 
different in each area. Admin is html navigation, site via use-cases, 
and authoring via menus. I think we should find a consistent navigation 
strategy (at least for the non-live parts). I'm not sure ATM which 
approach is best, but they definitely should be consistent. WDYT ?




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: usecase framework / navigation

Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:

[...]

> If I understand correctly, in the site (that is, info-authoring) area, 
> navigation is already a usecase. That is, user clicking on site triggers 
> the use case "show all available use cases for site, that is, meta, 
> assets, versions etc.". This use case is called "tab" (which BTW is not 
> a good wording, as it just names the GUI pattern, instead of what it 
> achieves).

In this case, the prefix actually is related to the tabbed display style.
In usecase.xmap, the view style is determined using the "tab." prefix.
If we find a better way to achieve this, we could use arbitrary
usecase names for the site area (workflow.history, rc.viewRevisions etc.)


> So I suppose that for the "admin" area we want to implement a 
> similar overview use-case, which would lead to the various admin 
> use-cases ?

I guess that would be a good idea.


> What I am wondering is, how far this idea of using use-cases to 
> implement navigation should go. Because if we take the idea of the site 
> navigation ("tab" usecase) further, the whole navigation would become 
> use cases. That would mean, in the admin/authoring area, after the login 
> usecase, the user is presented with the list of possible use cases. How 
> it is rendered is a different issue of course. If she chooses the 
> use-case "show admin use-cases", she is taken to the next step, i.e. 
> shown the available use-cases in admin area.
> 
> The same issue holds for the live website navigation. It might be 
> helpful to reflect upon website navigation as a usecase as well, I don't 
> know. I'm thinking roles, that is which user may see what, and perhaps 
> even (for the future) adapting the page to some situation, i.e. which 
> parts are shown in which situation. Since some hooks for logic are 
> needed anyway when delivering content in the live website, it might make 
> sense to think in terms of usecase framework.

Wow, that would be a big change ...
I have to think a little bit more about it.


> In any case, what is not so good at the moment in the 
> admin/site/authoring stuff, is that navigation concepts are entirely 
> different in each area.

Yes, I agree. Actually the admin area depends on a sitetree
as well, so authoring and admin are kind-of similar.


> Admin is html navigation, site via use-cases, 
> and authoring via menus. I think we should find a consistent navigation 
> strategy (at least for the non-live parts). I'm not sure ATM which 
> approach is best, but they definitely should be consistent. WDYT ?

Maybe you can write a RT/proposal about that? IMO it is very interesting.


-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org