Mailing List Archive: Trail vs. Log

Trail vs. Log

Apr 12, 2011, 10:28 AM

Post #1 of 4 (1981 views)

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

Re: Trail vs. Log [ In reply to ]

david at kineticode

Apr 12, 2011, 10:32 AM

Post #2 of 4 (1921 views)

Permalink

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

Re: Trail vs. Log [ In reply to ]

fulekia at denison

Apr 12, 2011, 10:40 AM

Post #3 of 4 (1906 views)

Permalink

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

Re: Trail vs. Log [ In reply to ]

david at kineticode

Apr 12, 2011, 11:00 AM

Post #4 of 4 (1927 views)

Permalink

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