Re: [development] Use revisions to replace previews
How hard would it be to add a third button? So you have "preview" "save draft" "save"? Save draft would go through what save normally does with the exception that it doesn't wipe out any existing "official" version of the node where "preview" would just show you without any sort of saving as it does now. I don't know about the code end but from the user end that makes sense to me. Michelle On 6/9/2007 4:48:32 PM, Dries Buytaert (dries.buytaert@gmail.com) wrote: I agree with this. As an excessive previewer myself, the mental model that lives in my head assumes that previews are volatile. I preview because I don't want to save my data before it's ready to be saved. I don't finish everything that I start writing so every once in a while, I abandon the post in which case the previews and the node ID would still be in the database? That said, I'm not opposed to an auto-save feature or a 'Save as draft' feature. Except that it should somehow align better with my mental model. Something else to consider -- spammers will often try to submit spam to your site. Even if they don't make it through, they might insert permanent junk in your database.
This is really necessary for many practical applications of Drupal. Please put yourselves in the place of end users. On 6/10/07, Michelle Cox <mcox@charter.net> wrote:
How hard would it be to add a third button? So you have "preview" "save draft" "save"? Save draft would go through what save normally does with the exception that it doesn't wipe out any existing "official" version of the node where "preview" would just show you without any sort of saving as it does now.
I don't know about the code end but from the user end that makes sense to me.
Michelle
On 6/9/2007 4:48:32 PM, Dries Buytaert (dries.buytaert@gmail.com) wrote: I agree with this. As an excessive previewer myself, the mental model that lives in my head assumes that previews are volatile. I preview because I don't want to save my data before it's ready to be saved. I don't finish everything that I start writing so every once in a while, I abandon the post in which case the previews and the node ID would still be in the database? That said, I'm not opposed to an auto-save feature or a 'Save as draft' feature. Except that it should somehow align better with my mental model.
Something else to consider -- spammers will often try to submit spam to your site. Even if they don't make it through, they might insert permanent junk in your database.
Hi, On zondag 10 juni 2007, Victor Kane wrote:
This is really necessary for many practical applications of Drupal. Please put yourselves in the place of end users.
Sure. But many don't need this exact workflow. Others don't need it at all. When Drupal harcodes such workflows, including things like "saving drafts" in its core, this is both annoying for developers and end users. * End-users that need some save draft, might find that the Drupal implementation is almost what they need, yet not exactly. Hence they might need it improved or altered. With something hardcoded this becomes very hard. Bad idea. * Developers that don't need this exact workflow, or need a far more advanced (Random example: Save to group Drafts, Save as private Draft etc) will need to spend a lot of time hacking the hardwired workflows out. Thereby breaking many contribs that, by that time, depend on that hardwired workflow, etc. What I am trying to say, is that this whole conversation about abusing revisions to show previews forgets the very fact that Drupal is not just for you and your case. There are many cases. Many details that differ from site to site, and project to project. If we all needed the exact same website with the exact same behaviour, then we can think about hardwiring such behaviour in a core. Therefore, lets simply keep this in our minds and lets not come up with nifty, detailed features for core. Save as Draft is a nice feature: but please propose this with the acitons/workflow project, or some other dedicated module. Using revisions for previews is a nice idea: but please instead rather discuss how to make previewing more modular, instead of proposing it as the one and only solution. AFAIKS all we *really* need is a hook_nodeapi #preview, or better even, a form alter #preview (to extend this preview beyond merely nodes). Then, any module can make its previews. CCK can use this to pre-calculate the previews. comment.module to simply render the data with some extra metadata. Media modules (there is no module that does /proper/ file handling on previes around) to show the files inline etc. But even if above idea of a #preview is silly, the point is, that we should think beyond our own cases. It has been a good thing that core has less and less hardwired workflow thingies in, ever since 4.7. Lets not turn these improvements back by going wild on all sorts of preview features in core. Regards, Bèr Kessels -- Bèr Kessels http://webschuur.com Webschuur.com IM: ber@jabber.webschuur.com Voorstadslaan 211 skype: webschuur 6541 SN Nijmegen Nederland/Netherlands
Certainly what you write is food for thought. But, surely, a "save and continue" button could be placed in as an option? Because the fundamental thing here, and this is not just a single case, is for Drupal to continue to grow as a web application framework. The absence of this option (even the frugal gmail interface includes a "Save Now" button as I write this) keeps Drupal in the "web" corner and doesn't allow it to be seen as a full fledged "application". Of course, modules such as autosave help here; but I do not think that a save and continue button is a single case; certainly it should be an option for all content types. saludos, Victor Kane http://awebfactory.com.ar On 6/10/07, Bèr Kessels <ber@webschuur.com> wrote:
Hi,
On zondag 10 juni 2007, Victor Kane wrote:
This is really necessary for many practical applications of Drupal. Please put yourselves in the place of end users.
Sure. But many don't need this exact workflow. Others don't need it at all. When Drupal harcodes such workflows, including things like "saving drafts" in its core, this is both annoying for developers and end users. * End-users that need some save draft, might find that the Drupal implementation is almost what they need, yet not exactly. Hence they might need it improved or altered. With something hardcoded this becomes very hard. Bad idea. * Developers that don't need this exact workflow, or need a far more advanced (Random example: Save to group Drafts, Save as private Draft etc) will need to spend a lot of time hacking the hardwired workflows out. Thereby breaking many contribs that, by that time, depend on that hardwired workflow, etc.
What I am trying to say, is that this whole conversation about abusing revisions to show previews forgets the very fact that Drupal is not just for you and your case. There are many cases. Many details that differ from site to site, and project to project. If we all needed the exact same website with the exact same behaviour, then we can think about hardwiring such behaviour in a core.
Therefore, lets simply keep this in our minds and lets not come up with nifty, detailed features for core. Save as Draft is a nice feature: but please propose this with the acitons/workflow project, or some other dedicated module. Using revisions for previews is a nice idea: but please instead rather discuss how to make previewing more modular, instead of proposing it as the one and only solution.
AFAIKS all we *really* need is a hook_nodeapi #preview, or better even, a form alter #preview (to extend this preview beyond merely nodes). Then, any module can make its previews. CCK can use this to pre-calculate the previews. comment.module to simply render the data with some extra metadata. Media modules (there is no module that does /proper/ file handling on previes around) to show the files inline etc.
But even if above idea of a #preview is silly, the point is, that we should think beyond our own cases. It has been a good thing that core has less and less hardwired workflow thingies in, ever since 4.7. Lets not turn these improvements back by going wild on all sorts of preview features in core.
Regards, Bèr Kessels -- Bèr Kessels http://webschuur.com Webschuur.com IM: ber@jabber.webschuur.com Voorstadslaan 211 skype: webschuur 6541 SN Nijmegen Nederland/Netherlands
Quoting Victor Kane <victorkane@gmail.com>:
Certainly what you write is food for thought.
But, surely, a "save and continue" button could be placed in as an option?
Because the fundamental thing here, and this is not just a single case, is for Drupal to continue to grow as a web application framework. The absence of this option (even the frugal gmail interface includes a "Save Now" button as I write this) keeps Drupal in the "web" corner and doesn't allow it to be seen as a full fledged "application".
Of course, modules such as autosave help here; but I do not think that a save and continue button is a single case; certainly it should be an option for all content types.
A save now button makes sense where it is left unpublished regardless of the workflow setting. This should be easily accomplished but so is dropping down the workflow and unmarking the radio button. Earnie
Hi, On zondag 10 juni 2007, Victor Kane wrote:
But, surely, a "save and continue" button could be placed in as an option?
Let me put "core" into perspective here: I deliberately mentioned "hardwired" and "hardcoded" several times in my post. Thing is, Drupal can have proper time-based, hot, or even hyped features in core. In fact: I'd love it to have more of that. Where was the wet floor effect when it was stil cool? No, my aversion is against hardcoding this. Which is what this thread has talked about a lot. Instead of looking for the modular solution, we have read about many pro's and cons of one specific implmentation. That is what bothers me. We should look at the real issue: Drupal needs better preview options. And from there, look at the options to solve that (#preview FAPI options, hook_preview, whatever). Instead of clinging to a solution for only a minor subset of our audience and harwiring that into our workflow. Regards, Bèr Kessels -- Bèr Kessels http://webschuur.com Webschuur.com IM: ber@jabber.webschuur.com Voorstadslaan 211 skype: webschuur 6541 SN Nijmegen Nederland/Netherlands
It occurs to me that maybe [preview] [save] and [publish] are the actions / verbs which might make sense. If a site is configured with a workflow where authors cannot publish directly, but need an editor approval first, then of course the [publish] button is not displayed.
Quoting Chris Johnson <cxjohnson@gmail.com>:
It occurs to me that maybe [preview] [save] and [publish] are the actions / verbs which might make sense. If a site is configured with a workflow where authors cannot publish directly, but need an editor approval first, then of course the [publish] button is not displayed.
But in the later scenario I might not be ready for the editor to publish it. I would always want a [preview] without saving to the DB. I would want [draft] to save a working copy for later revision by me and only me. And I would then want a [ready] for an editor to publish. If I was editor then I would get the [publish] button instead of the [ready] button. Earnie
On 6/11/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:
But in the later scenario I might not be ready for the editor to publish it. I would always want a [preview] without saving to the DB. I would want [draft] to save a working copy for later revision by me and only me. And I would then want a [ready] for an editor to publish. If I was editor then I would get the [publish] button instead of the [ready] button.
That's actually an improvement that I thought about adding to the workflow module. Instead of having a radio-button allowing to set the workflow status, having buttons for every available workflow status would be clearer (from a user prospective, you'd expect a change of the status setting to be reversible, whereas buttons clearly indicate an action being performed). I haven't heard anything about integrating the workflow module in core (maybe something to consider at some point?) but we could already have this enabled for the basic core workflow. Florian
The below is actually how I had to code up the last user-submitted content site we made. Separate buttons which execute that state change versus the radio pick and the 'submit' button would be a good improvement. How could we help implement this change directly into workflow? -Greg ________________________________ From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Florian Loretan Sent: Monday, June 11, 2007 6:01 AM To: development@drupal.org Subject: Re: [development] AB-Use revisions to replace previews On 6/11/07, Earnie Boyd <earnie@users.sourceforge.net> wrote: But in the later scenario I might not be ready for the editor to publish it. I would always want a [preview] without saving to the DB. I would want [draft] to save a working copy for later revision by me and only me. And I would then want a [ready] for an editor to publish. If I was editor then I would get the [publish] button instead of the [ready] button. That's actually an improvement that I thought about adding to the workflow module. Instead of having a radio-button allowing to set the workflow status, having buttons for every available workflow status would be clearer (from a user prospective, you'd expect a change of the status setting to be reversible, whereas buttons clearly indicate an action being performed). I haven't heard anything about integrating the workflow module in core (maybe something to consider at some point?) but we could already have this enabled for the basic core workflow. Florian
On 6/11/07, Chris Johnson <cxjohnson@gmail.com> wrote:
It occurs to me that maybe [preview] [save] and [publish] are the actions / verbs which might make sense. If a site is configured with a workflow where authors cannot publish directly, but need an editor approval first, then of course the [publish] button is not displayed.
If we do it this way, we have actions/verbs on the UI that match with what actually happens in the back-end. Considering that most people new to drupal are both users and "developers" (in the sense that they install and configure drupal,), having things consistent this way really keep us from having questions like "When I click on preview/save/submit/etc, [unexpected behavior]" showing up in the forums way too often.
On 6/11/07, Florian Loretan <floretan@gmail.com> wrote:
Considering that most people new to drupal are both users and "developers" (in the sense that they install and configure drupal,)
I disagree. Most people new to Drupal are simply users, and generally unsophisticated, non-technical users. I set up Drupal sites for thousands of users. None of them ever install or configure Drupal. They are people who have information, communication and collaboration needs. They want to inform, communicate and share with other users. They don't want the system to get in their way. I agree that Earnie's refinement of my suggestion is very good: [ready] to publish versus [save] a draft is definitely something that should be possible in the workflow. That was a fairly large oversight on my part. Core should allow it, but perhaps the actually ability to DO it should be in a contributed workflow-oriented module.
While I agree with Ber that we shouldn't force one workflow in core, we do need to establish a common data model for it. Otherwise, there's no way for contrib modules to arbitrarily tie into it. Right now, some contribs just store nid. Technically that's wrong because then versioning doesn't work; they need nid and vid. If we want "drafts in core", then we also have to have some mechanism for contribs to "just work" with whatever the draft mechanism is. (A did column? Just reusing vid? Actions in core? Something else? I don't know.) If we don't, you'll be able to save-as-draft the title and body and little else, which is rather pointless. :-) On Sunday 10 June 2007, Bèr Kessels wrote:
Hi,
On zondag 10 juni 2007, Victor Kane wrote:
This is really necessary for many practical applications of Drupal. Please put yourselves in the place of end users.
Sure. But many don't need this exact workflow. Others don't need it at all. When Drupal harcodes such workflows, including things like "saving drafts" in its core, this is both annoying for developers and end users. * End-users that need some save draft, might find that the Drupal implementation is almost what they need, yet not exactly. Hence they might need it improved or altered. With something hardcoded this becomes very hard. Bad idea. * Developers that don't need this exact workflow, or need a far more advanced (Random example: Save to group Drafts, Save as private Draft etc) will need to spend a lot of time hacking the hardwired workflows out. Thereby breaking many contribs that, by that time, depend on that hardwired workflow, etc.
What I am trying to say, is that this whole conversation about abusing revisions to show previews forgets the very fact that Drupal is not just for you and your case. There are many cases. Many details that differ from site to site, and project to project. If we all needed the exact same website with the exact same behaviour, then we can think about hardwiring such behaviour in a core.
Therefore, lets simply keep this in our minds and lets not come up with nifty, detailed features for core. Save as Draft is a nice feature: but please propose this with the acitons/workflow project, or some other dedicated module. Using revisions for previews is a nice idea: but please instead rather discuss how to make previewing more modular, instead of proposing it as the one and only solution.
AFAIKS all we *really* need is a hook_nodeapi #preview, or better even, a form alter #preview (to extend this preview beyond merely nodes). Then, any module can make its previews. CCK can use this to pre-calculate the previews. comment.module to simply render the data with some extra metadata. Media modules (there is no module that does /proper/ file handling on previes around) to show the files inline etc.
But even if above idea of a #preview is silly, the point is, that we should think beyond our own cases. It has been a good thing that core has less and less hardwired workflow thingies in, ever since 4.7. Lets not turn these improvements back by going wild on all sorts of preview features in core.
Regards, Bèr Kessels
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
participants (9)
-
Bèr Kessels -
Chris Johnson -
Earnie Boyd -
Florian Loretan -
Greg Holsclaw -
Karoly Negyesi -
Larry Garfield -
Michelle Cox -
Victor Kane