Mailing List Archive: Bricolage: users

Trail vs. Log

Index | Next | Previous | View Threaded

fulekia at denison

Apr 12, 2011, 10:28 AM

Post #1 of 4 (469 views)
Permalink

Trail vs. Log

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
---------------------------------

david at kineticode

Apr 12, 2011, 10:32 AM

Post #2 of 4 (433 views)
Permalink

Re: Trail vs. Log [In reply to]

On Apr 12, 2011, at 10:28 AM, Aaron Fuleki wrote:

> 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.

Is there not still also a "Log" link?

> 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.

You can select to diff previous versions right there, no?

David

fulekia at denison

Apr 12, 2011, 10:40 AM

Post #3 of 4 (430 views)
Permalink

Re: Trail vs. Log [In reply to]

>> 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.
>
> Is there not still also a "Log" link?

On the workspace view, yes. I was talking about the profile view, when editing an asset. I'm trying to get an idea if anyone else's users also ignore/misunderstand the "Trail" link, or if that's mostly an artifact of our docs, training, and workflow configuration.

>> 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.
>
> You can select to diff previous versions right there, no?

Yeah, but a history view would show a simple list of names and timestamps. That's hella more context than a list of version numbers, and easier than clicking back and forth on a bunch of diff screens. We have some stories with hundreds of versions, so diff'ing can take ages.

In general, I'm trying to think of cheap & easy ways to give the profile view richer context, so users have an easier time with things. Feel free to shoot down bad ideas ;-)

-Aaron

---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------

david at kineticode

Apr 12, 2011, 11:00 AM

Post #4 of 4 (437 views)
Permalink

Re: Trail vs. Log [In reply to]

On Apr 12, 2011, at 10:40 AM, Aaron Fuleki wrote:

> On the workspace view, yes. I was talking about the profile view, when editing an asset. I'm trying to get an idea if anyone else's users also ignore/misunderstand the "Trail" link, or if that's mostly an artifact of our docs, training, and workflow configuration.

Okay.

> Yeah, but a history view would show a simple list of names and timestamps. That's hella more context than a list of version numbers, and easier than clicking back and forth on a bunch of diff screens. We have some stories with hundreds of versions, so diff'ing can take ages.

It shouldn't. But the select list could have timestamps added to it. I think that makes sense. Would that do?

> In general, I'm trying to think of cheap & easy ways to give the profile view richer context, so users have an easier time with things. Feel free to shoot down bad ideas ;-)

Sure. And don't worry, I will. So far nothing bad, though.

David

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads