comments below ...
Matt Raible wrote:
On 6/29/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Hopefully we'll hear from a wider set of people about this, but I am
still wondering what the use case is for these edit links. How are you
guys actually using them? You actually move back and forth between the
authoring interface and your rendered weblog to edit entries?
Yes, I use it all the time for that. It's a force of habit more than
anything. If I was smart, I'd use two tabs, but after posting
thousands of blog entries, habits form. ;-)
That was basically what I was thinking but couldn't articulate it for
some reason. It does seem more to me like this is a feature that some
people may be used to because it's there, not because there is a real
need for it.
And just so that we are not misunderstood, I am not just objecting to
this feature because I don't happen to use it. I am really just trying
to offer an objective question of ... is this feature really the best
way to accomplish the problem it is trying to solve? more specifically,
do these edit links on the rendered weblog pages really serve as the
right way to work on weblog authoring while having a chance to get a
full view of the changes? it seems that the only benefit these links
offer over their counterparts in the authoring interface is that they
allow you to see the rendered weblog at the same time, and I fully admit
that can be beneficial at times.
I can see a reason why you might publish and entry and go immediately to
your blog page to take a final look at it, then decide you need to make
an edit, but aside from the past entry or 2 i don't see why you would
first login to the authoring interface and then navigate to your weblog
so that you can edit an entry that is multiple days/months old. Or why
you would login to the authoring interface and then navigate to your
blog so that you can use the "Website:Settings" link there instead of
just using the link on the main menu page of the authoring interface.
In any case, as an alternative I would probably propose that instead of
linking back and forth between the fully published weblog pages and the
authoring interface that we instead expand the capabilities of the
preview servlet to meet this need instead. The preview servlet seems
like the ideal venue for this exact situation and can offer *way* more
benefits since we can do things with the preview servlet which we
wouldn't be able to do on the real pages.
For example, perhaps the preview servlet should render draft entries so
that the weblog author can see how their entry will fit in with the
entire rendered page, rather than using the fairly simple entry preview
mode that we have now? This way you can get a true preview of the way
the entry will look, but without having to publish it first. Also,
maybe we can find a way to setup the preview servlet so that it can
render using unsaved template changes as well. That would be extremely
beneficial since you would be able to work on templates without having
to affect how your rendered blog looks. And on and on.
My goal is not to rip out a valid feature, it's more to question whether
that feature is really appropriate and if it can be done in a better way.
-- Allen
Matt
I think my biggest hang-up is that I have never heard of a content
publishing system that actually ties it's rendered content together with
it's publishing interface. It seems strange to me that rendered content
(static content) should try and have a reference back to the publishing
system.
anyways ...
-- Allen
Matt Raible wrote:
> I agree with Dave, -1 on removing Edit links from posts when logged in
> as an author.
>
> Matt
>
> On 6/29/06, Dave Johnson <[EMAIL PROTECTED]> wrote:
>> -1 on removing edit links and in-line menu.
>>
>> I use them many times a day and conside them extremely useful.
>>
>> - Dave
>>
>>
>>
>> On 6/29/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>> > I would agree with your point that the little "edit" links on
>> entries is
>> > the less useful element, but I still consider that little editor
>> menu to
>> > be a bit out of context.
>> >
>> > The menu itself is nice and I suggest we continue using it,
however it
>> > makes way more sense to me for that to be part of the authoring
>> > interface rather than on *all* weblog pages. I can see a little
menu
>> > like that being on the main menu page.
>> >
>> > I am also yet to understand why it makes any sense for a weblog
page to
>> > be knowledgeable about the login status of a user. You login to the
>> > authoring interface, not a weblog. To me the rendered weblog
pages are
>> > a completely separate system from the authoring system (which is
>> > basically the case in the code as well) and they shouldn't be tied
>> together.
>> >
>> > -- Allen
>> >
>> >
>> > Martin Giljohann wrote:
>> > > I like the idea of simplifying the blog UIs and from my point of
>> view the edit link is somewhat unnecessary.
>> > >
>> > > However I disagree with the general idea of not considering
>> authorization for the blog templates, because I regard e.g. the
>> navigation menu as being pretty useful in terms of having a shortcut
>> for the author for posting new entries and manage the settings. This
>> is a usability feature which I would personally weight higher than
>> speeding up the caching.
>> > >
>> > > Regards
>> > > Martin
>> > >
>> > >
>> > > Allen Gilliland wrote:
>> > >
>> > >> I know I have brought this up before and I don't remember how it
>> was received, but in any case I'm going to bring it up again. Would
>> anyone be opposed to the idea of removing the set of edit links that
>> we embed into weblog pages? I think the reasons to do this are
many ...
>> > >>
>> > >> 1. It would *significantly* simplify the page rendering process
>> to not have to deal the issue of rendering things differently if the
>> weblog owner is logged in. I believe there is a fair amount of logic
>> that goes into the models/macros/rendering to deal with this situation
>> which could all be removed.
>> > >>
>> > >> 2. I consider this feature minimally useful. I don't see why a
>> weblog author would browser their site to look for things to edit
>> rather than just logging into the "editing" interface and doing their
>> work their.
>> > >>
>> > >> 3. This feature is only ever of benefit to a single person, the
>> weblog author. We add a fair amount of extra logic just so that these
>> pages can be rendered to benefit a single person :/
>> > >>
>> > >> 4. This would never work in a statically rendered site.
>> > >>
>> > >> As far as I am concerned this feature requires way more overhead
>> than it's worth. If we rip it out we simplify a number of things ...
>> > >>
>> > >> 1. we can remove all elements of models and macros which perform
>> any logic based on a users login status. this would simplify a number
>> of models and macros.
>> > >>
>> > >> 2. we can simplify our caching because the cache no longer needs
>> to know if the user is logged in or not and render/cache those pages
>> separately. this reduces the size of the cache (possibly
>> significantly on large sites) and eliminates unnecessary redundancy.
>> > >>
>> > >> So, my opinion is pretty obvious. I think this is a feature
>> which can safely be removed and will do some very good things to
>> simplify a number of aspects of weblog rendering.
>> > >>
>> > >> Thoughts? Opinions?
>> > >>
>> > >> -- Allen
>> > >>
>> > >>
>> > >
>> > >
>> >
>>
