Another quirk I noticed while revamping our documentation: the "Trail" link on the profile screen.
I don't think our users have ever really gotten what it is, but perhaps that's just because we tend to have a shallow workflow environment, with little movement between desks.
In bric 1, the trail link takes you to '/workflow/trail/<story|media>/<ID>', which shows a list of desk move events. I guess this might be useful in environments with deep workflows, but our users are usually much more interested in the version history, which is tied to check in events.
In bric 2, the "Trail" link now just takes you to the generic log view, passing a filter arg to the JavaScript, so that it only shows desk moves.
I think it would be much more useful to just make it a "Log" link and show the full asset event log. If users want to filter it, they now have that option, which is sweet.
I'm also rewriting some docs which explain the whole versioning and reverting concept. A 'history' link next to the revert button (showing a log filtered on check in events) would be an excellent way to create a meaningful context for the revert function.
What do folks think of either of those suggestions?
-Aaron
---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------
I don't think our users have ever really gotten what it is, but perhaps that's just because we tend to have a shallow workflow environment, with little movement between desks.
In bric 1, the trail link takes you to '/workflow/trail/<story|media>/<ID>', which shows a list of desk move events. I guess this might be useful in environments with deep workflows, but our users are usually much more interested in the version history, which is tied to check in events.
In bric 2, the "Trail" link now just takes you to the generic log view, passing a filter arg to the JavaScript, so that it only shows desk moves.
I think it would be much more useful to just make it a "Log" link and show the full asset event log. If users want to filter it, they now have that option, which is sweet.
I'm also rewriting some docs which explain the whole versioning and reverting concept. A 'history' link next to the revert button (showing a log filtered on check in events) would be an excellent way to create a meaningful context for the revert function.
What do folks think of either of those suggestions?
-Aaron
---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------