Highlighting draft status

[Kenneth Bolton]

Hi Mezzaniners,

The one issue with which my clients always seem to struggle is that draft content shows up like published content when they browse the site. I took at stab this morning at mucking with the templates and css to highlight draft content. The basic implementation is trivial. That all said, I am no designer nor UI expert. My fumbling just adds "(Draft)" in red 12px text where appropriate.

Do others have this problem? Anyone have creative ideas on how to draw appropriate attention to draft content?

best,

ken

[Josh Cartmell]

I have thought about this and struggled with it as well.

The problem I have run into with adding the word draft (which I have done before) is that it causes the menu to not actually look the way it will if the content were published, for example it can cause the menu to spill onto the lines it wouldn't normally.

I see the value of both highlighting things as drafts and not highlighting them.  Not pointing out drafts allows you to see exactly what users will see if you publish the drafts.  Highlighting drafts in some way makes it much easier to keep track of what users are currently seeing and what is a draft.
I just had an idea which is mark drafts with two css classes, one that simply identifies it as a draft and one that applies styling to highlight it as a draft.  Then we could add a button in the top left by Admin and Logout, maybe Toggle Drafts, that when clicked would toggle the class that actually styles drafts on anything that has the draft style.  That way admin users could see exactly what end users will see when they want and have drafts highlighted when they want.  I think the default would be to have draft mode enabled.  Mezzanine's css could apply some basic styling for the draft style class and then any project would be free to implement their own.

Hopefully that made sense.  What do you think?

[Ken Bolton]

Hmm. Interesting. How about a toggle to show/hide draft content?

[Stephen McDonald]

I've had this pain point too - especially when admins see draft content, then forget to publish it.

I love the idea of a global toggle for the user - it could be a button that sites in the main live-editing toolbar (top left corner of the page) that just says Show/Hide drafts. Rather than messing with CSS which can often conflict with the design of the site, we could use a session variable and just check that when we call the manager and choose whether or not to load draft content.

--
Stephen McDonald
http://jupo.org

[Josh Cartmell]

I think that would be great Ken and Steve!

I do wanna push back a bit on styling drafts differently somehow.  I think there is additional value to be gained from highlighting drafts somehow and potentially allowing admins to toggle that.  I see this as value above and beyond toggling showing drafts which I do think would be very valuable.

If you have a lot of pages, and many of them in dropdowns toggling back and forth between showing drafts and hiding them won't necessarily be enough for an admin to know what is a draft and what isn't and they could still run into the problem of forgetting to publish content (although probably not as easily).  If we did apply any css I would think it should be non-invasive layout wise but still eye catching (maybe an orange background).  It would be a bit disruptive to the design, but that would be the purpose, to draw an Admin's attention.  Allowing it to be toggled would still provide the opportunity to see the design undisturbed.

[Ken Bolton]

For your review: https://github.com/kenbolton/mezzanine/commit/6edf55d02ab7726d065cc2f316a1a0400465a3b8

Happy to entertain suggestions for improvements.

best,

ken

[Stephen McDonald]

Thanks Ken - on the surface it looks great.

There's a big design question though that for me at least I'd like to think about a bit for a while - with this change we now introduce the idea of getting at the current request inside the manager. It's very different than how checking published objects against a user works - up until now we've passed in the user explicitly everywhere. I think both these things (user and session flag for drafts) should use the same approach. Either pass it in explicitly (we might change passing the user in to pass the request in instead) or get it implicitly from the threadlocal request. 

It's a big design question as it shapes the overall approach of how we deal with the disconnect between models/managers (data) and actual website requests. Personally I'm leaning towards overhauling things and using the request implicitly as you have, and change it so that we don't pass the user around anymore. But this gets into the realm of what people would call magic, and there may be other caveats, but if it all works cleanly I'm all for the implicit magic way of doing it.

Would love to hear more thoughts on this area, particularly around the higher level design of passing requests around vs getting it from the threadlocal var.

[Kenneth Bolton]

Stephen: Thank you, thank you, thank you. Contributing to Mezzanine in my small way continues to be a thrilling way to improve my understanding of Django, Python and the tools of literate software development. 

I took that approach because I found that usage in mezzanine.utils.sites.current_site_id(), which looks like the only place mezzanine.core.request.current_request() gets used in stephenmcd/mezzanine/'s master branch.

On to the BDQ (big design question). I'm not crazy about the idea of requiring the request to be passed into a Manager's methods; that would make model manipulation marginally more complicated in the shell. (Ooooh, alliteration!) I suppose if the request were a keyword arg, e.g. `request=None`, I could get behind that approach.

I would relish the opportunity to tackle this refactor. Do let me know.

best,

ken

[Ken Bolton]

Mulling this over after my stab at implementing this at the Manager level, I agree in principle, but think the implementation should probably be up to individual developers/teams. Just my opinion at the moment, and subject to change.

[Stephen McDonald]

Perhaps a good baby step without committing to the overall design decision we've talked about, would be to refactor for_user to accept a request object instead of a user object - then we can get at both the request and the session. That way the current approach would stay as is, but we'd get access to the new session flag for toggling drafts.

[Stephen McDonald]

Just realised another point to add to this design decision - all of the site relationship lookups in managers make use of the threadlocal middleware and we never pass a site around by default - so we actually use both patterns at the moment throughout Mezzanine.