Mailing List Archive

Comments re: previewing and story state?
Hi everybody,


I just got off the phone with Greg; we were talking about how the
Bricolage preview function might be changed and I think we've got a
pretty good idea. But I thought I should post our thoughts to the list
before building any of those changes, in case anybody has a better idea
than what we're proposing.

Here's the problem:

Some of our templates cause edits to stories. The best example is the
image resize and relate template, which takes a high-res picture and
creates multiple thumbnails, and then adds a container element for each
one of those thumbnails.

If you trigger a preview from the UI, while you're looking at the
profile of an element that will have children added by the preview, and
then you click "save," Bricolage throws a "state inconsistent" error,
because the new children are present in the story but are not in the
form being submitted.

So we want to make that error go away, and we also want to make sure the
UI shows story's elements in their current state.


Here's our proposed change (which could be turned on or off with a
configuration directive):

1. Instead of having the preview triggered from a popup browser window,
trigger it from the UI window. When "preview" is clicked, pop up an
in-window AJAX notice (a "modal" or a "fader" or whatever those things
are called) that the preview is in progress.

2. When the preview is complete and the callback tells the browser so,
have the modal notice change to offer a link to the preview. Clicking
that link would open a new browser and display the previewed document.

3. Meanwhile, because the UI window was be the one that actually called
the preview, it could be smart about refreshing its own view of the
story and its elements.


Turning the directive off would leave the preview process exactly as it
is, with previews executed by popup windows.


Anyway, I'd love to hear people's thoughts about the idea.


Thanks,

Bret

--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com
Re: Comments re: previewing and story state? [ In reply to ]
On 18-Nov-08, at 5:08 PM, Bret Dawson wrote:

> 2. When the preview is complete and the callback tells the browser so,
> have the modal notice change to offer a link to the preview. Clicking
> that link would open a new browser and display the previewed document.

I think this part would be automatic; when the preview has been built,
the Bricolage window will go on to step three after opening a new
window as usual with the preview content. No need for a second click
to get the preview. Any errors would go right in the modal and no
preview window would pop up.

One downside we discussed is the loss of the "Repreview" function in
the preview window (the new preview will look like the current one but
without the frameset).
Re: Comments re: previewing and story state? [ In reply to ]
On Nov 18, 2008, at 2:08 PM, Bret Dawson wrote:

> Here's our proposed change (which could be turned on or off with a
> configuration directive):
>
> 1. Instead of having the preview triggered from a popup browser
> window,
> trigger it from the UI window. When "preview" is clicked, pop up an
> in-window AJAX notice (a "modal" or a "fader" or whatever those things
> are called) that the preview is in progress.
>
> 2. When the preview is complete and the callback tells the browser so,
> have the modal notice change to offer a link to the preview. Clicking
> that link would open a new browser and display the previewed document.

*Two* clicks? Ew.

> 3. Meanwhile, because the UI window was be the one that actually
> called
> the preview, it could be smart about refreshing its own view of the
> story and its elements.

What if the user has made changes since the last save but before the
preview? Those changes would be lost.

> Turning the directive off would leave the preview process exactly as
> it
> is, with previews executed by popup windows.

I'm fine to change things, but want to start to get tougher about
letting in directives. There are already way too many, and it's silly
to have them for UI stuff, frankly.

> Anyway, I'd love to hear people's thoughts about the idea.

How about if you click the preview link, it turns into some sort of
status icon showing that the render is in process, and when it
finishes, it automatically opens a new window for the actual preview?

Best,

David
Re: Comments re: previewing and story state? [ In reply to ]
On Nov 18, 2008, at 3:26 PM, Greg Heo wrote:

> On 18-Nov-08, at 5:08 PM, Bret Dawson wrote:
>
>> 2. When the preview is complete and the callback tells the browser
>> so,
>> have the modal notice change to offer a link to the preview. Clicking
>> that link would open a new browser and display the previewed
>> document.
>
> I think this part would be automatic; when the preview has been
> built, the Bricolage window will go on to step three after opening a
> new window as usual with the preview content. No need for a second
> click to get the preview. Any errors would go right in the modal and
> no preview window would pop up.
>
> One downside we discussed is the loss of the "Repreview" function in
> the preview window (the new preview will look like the current one
> but without the frameset).

You could just make it the same link with progress and autoload of the
preview, no?

Best,

David
Re: Comments re: previewing and story state? [ In reply to ]
Bad wording on my part; you can of course re-preview as often as you
like but the preview function will be only in the main Bricolage
window and not on the preview itself.

Very often I have the main Bricolage window up editing/saving a
template and I can re-preview from the separate window while the
template is still sitting in edit mode.


On 18-Nov-08, at 7:00 PM, David E. Wheeler wrote:

>> One downside we discussed is the loss of the "Repreview" function
>> in the preview window (the new preview will look like the current
>> one but without the frameset).
>
> You could just make it the same link with progress and autoload of
> the preview, no?
Re: Comments re: previewing and story state? [ In reply to ]
On Nov 18, 2008, at 4:08 PM, Greg Heo wrote:

> Bad wording on my part; you can of course re-preview as often as you
> like but the preview function will be only in the main Bricolage
> window and not on the preview itself.
>
> Very often I have the main Bricolage window up editing/saving a
> template and I can re-preview from the separate window while the
> template is still sitting in edit mode.

I don't follow.

Best,

David
Re: Comments re: previewing and story state? [ In reply to ]
After running a preview, I keep that window (with the frameset and
"Repreview" link) open. In the main Bricolage window, I then open a
template for editing. Then I edit the template, "save and stay",
switch to the preview window, re-preview, check the template changes,
switch back to the Bricolage window, repeat.

With the proposed changes, there wouldn't be a "Repreview" in the
preview itself since it will no longer be a frameset, but point
directly to the preview URL.


On 18-Nov-08, at 7:13 PM, David E. Wheeler wrote:

>> Very often I have the main Bricolage window up editing/saving a
>> template and I can re-preview from the separate window while the
>> template is still sitting in edit mode.
>
> I don't follow.
>
> Best,
>
> David
Re: Comments re: previewing and story state? [ In reply to ]
Hi,

I think that both ways make sense but it should definitely be a config
directive. When I'm developing it's very useful and much quicker to be able
to have template in one window and preview in the other but, in a
production environment then users should be forced down the path of least
risk to the CMS.

So config directive please :-)

regards,

Paul

--
Paul Orrock Digital Craftsmen
Lead SysAdmin www.digitalcraftsmen.net
Exmouth House, 3 Pine Street, London, EC1R 0JH
Tel: 020 7183 1410 Fax: 020 7099 5140
Re: Comments re: previewing and story state? [ In reply to ]
Paul Orrock wrote:
> So config directive please :-)

Config directives Must Die !

In particular what works in one site may not work in another site hosted
in the same system.

If it must be configurable it should be per user or per site basis.
Global configs for anything other than that needed to get Bricolage to
actually run should go. We have a database, we should use it.

Simon.

--
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, London. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcraftsmen.net/
Re: Comments re: previewing and story state? [ In reply to ]
Greg Heo wrote:
> Very often I have the main Bricolage window up editing/saving a template
> and I can re-preview from the separate window while the template is
> still sitting in edit mode.

In which case you're not looking at the story edit screen so it doesn't
matter if the story changes underneath you.

Could you not have the republish button in the preview window "talk" to
its parent window and if that's on the same story page get the
re-preview triggered from the parent instead of the child ?

S.

--
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, London. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcraftsmen.net/
Re: Comments re: previewing and story state? [ In reply to ]
In general, I'm not in favor of the proposed changes - I think it
would make the ui more complex when it needs to be stripped down.
David makes some good points. That being said, I'm not opposed to
major ui changes - we've been discussing thing on our end, too.

From our perspective, we do similar things with images, but we don't
get the inconsistent state errors. Maybe it's a question of
implementation?

-Matt


On Nov 18, 2008, at 5:08 PM, Bret Dawson wrote:

> Hi everybody,
>
>
> I just got off the phone with Greg; we were talking about how the
> Bricolage preview function might be changed and I think we've got a
> pretty good idea. But I thought I should post our thoughts to the list
> before building any of those changes, in case anybody has a better
> idea
> than what we're proposing.
>
> Here's the problem:
>
> Some of our templates cause edits to stories. The best example is the
> image resize and relate template, which takes a high-res picture and
> creates multiple thumbnails, and then adds a container element for
> each
> one of those thumbnails.
>
> If you trigger a preview from the UI, while you're looking at the
> profile of an element that will have children added by the preview,
> and
> then you click "save," Bricolage throws a "state inconsistent" error,
> because the new children are present in the story but are not in the
> form being submitted.
>
> So we want to make that error go away, and we also want to make sure
> the
> UI shows story's elements in their current state.
>
>
> Here's our proposed change (which could be turned on or off with a
> configuration directive):
>
> 1. Instead of having the preview triggered from a popup browser
> window,
> trigger it from the UI window. When "preview" is clicked, pop up an
> in-window AJAX notice (a "modal" or a "fader" or whatever those things
> are called) that the preview is in progress.
>
> 2. When the preview is complete and the callback tells the browser so,
> have the modal notice change to offer a link to the preview. Clicking
> that link would open a new browser and display the previewed document.
>
> 3. Meanwhile, because the UI window was be the one that actually
> called
> the preview, it could be smart about refreshing its own view of the
> story and its elements.
>
>
> Turning the directive off would leave the preview process exactly as
> it
> is, with previews executed by popup windows.
>
>
> Anyway, I'd love to hear people's thoughts about the idea.
>
>
> Thanks,
>
> Bret
>
> --
> Bret Dawson
> Producer
> Pectopah Productions Inc.
> (416) 895-7635
> bret@pectopah.com
> www.pectopah.com
>
Re: Comments re: previewing and story state? [ In reply to ]
On Nov 19, 2008, at 6:19 AM, Greg Heo wrote:

> After running a preview, I keep that window (with the frameset and
> "Repreview" link) open. In the main Bricolage window, I then open a
> template for editing. Then I edit the template, "save and stay",
> switch to the preview window, re-preview, check the template
> changes, switch back to the Bricolage window, repeat.
>
> With the proposed changes, there wouldn't be a "Repreview" in the
> preview itself since it will no longer be a frameset, but point
> directly to the preview URL.

I think it should be kept as a frameset.

Best,

David
Re: Comments re: previewing and story state? [ In reply to ]
On Nov 19, 2008, at 6:48 AM, Simon Wilcox wrote:

> Paul Orrock wrote:
>> So config directive please :-)
>
> Config directives Must Die !
>
> In particular what works in one site may not work in another site
> hosted in the same system.
>
> If it must be configurable it should be per user or per site basis.
> Global configs for anything other than that needed to get Bricolage
> to actually run should go. We have a database, we should use it.

+1

David
RE: Comments re: previewing and story state? [ In reply to ]
For what it's worth, I recently transition to removing the frameset
myself and have the code to permit this. It's an easy patch. I was
driven to this end because there appears to be either a bug in Firefox
3.x (or possibly in a DLL used in our standard desktop image) that
causes Firefox to freeze up when the preview is loading inside the
frameset.

Now that I have the patch in place, I actually prefer it to the frameset
and none of my users have complained (yet).

Anyway, it's implemented as yet another configuration option.

-----Original Message-----
From: David E. Wheeler [mailto:david@kineticode.com]
Sent: Wednesday, November 19, 2008 2:37 PM
To: devel@lists.bricolage.cc
Subject: Re: Comments re: previewing and story state?

On Nov 19, 2008, at 6:19 AM, Greg Heo wrote:

> After running a preview, I keep that window (with the frameset and
> "Repreview" link) open. In the main Bricolage window, I then open a
> template for editing. Then I edit the template, "save and stay",
> switch to the preview window, re-preview, check the template
> changes, switch back to the Bricolage window, repeat.
>
> With the proposed changes, there wouldn't be a "Repreview" in the
> preview itself since it will no longer be a frameset, but point
> directly to the preview URL.

I think it should be kept as a frameset.

Best,

David
Re: Comments re: previewing and story state? [ In reply to ]
On 18-Nov-08, at 5:08 PM, Bret Dawson wrote:

> 1. Instead of having the preview triggered from a popup browser
> window,
> trigger it from the UI window. When "preview" is clicked, pop up an
> in-window AJAX notice (a "modal" or a "fader" or whatever those things
> are called) that the preview is in progress.
>
> 2. When the preview is complete and the callback tells the browser so,
> have the modal notice change to offer a link to the preview. Clicking
> that link would open a new browser and display the previewed document.
>
> 3. Meanwhile, because the UI window was be the one that actually
> called
> the preview, it could be smart about refreshing its own view of the
> story and its elements.

FWIW -- I understand what you're driving at here Bret, e.g.:

You have a template that -- when previewed -- interacts with the story
asset itself, perhaps adding related stories, or related images. But,
because you've clicked preview _from_ the story, the story asset
screen doesn't reflect those changes.

I've experienced that myself with a utility template that "collects"
stories published in the last week and adds them to the calling story
as related stories. For this, I've taken to just creating the story,
saving it (not "Save and stay"), and always previewing from "My
Workspace" vs. the story itself.

So, I'm wondering why you couldn't do this:

* Click preview from the story editing UI and pop up the frameset
preview (which *is* super helpful when working on templates)
* Have the frameset refresh the main story editing screen after the
preview is rendered

Not entirely sure how that would work technically... but maybe
"Preview" could force the main story editing UI to refresh in some
AJAX-y way? Or to check for state changes and indicate that it needs
to reload?

2 cents,

Phillip.

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca
Re: Comments re: previewing and story state? [ In reply to ]
On Nov 21, 2008, at 5:21 AM, Phillip Smith wrote:

> So, I'm wondering why you couldn't do this:
>
> * Click preview from the story editing UI and pop up the frameset
> preview (which *is* super helpful when working on templates)
> * Have the frameset refresh the main story editing screen after the
> preview is rendered

This is the wrong solution to the problem. If you do this, any changes
the user has made since the last change will be lost.

A better solution is to add proper callbacks and plugins, and then
write a plugin that does the associating from within a save() callback.

Details on a plan here:

http://justatheory.com/bricolage/design/tasks_jobs_actions.html

I'd probably plan something simpler today. What do you think?

Best,

David
Re: Comments re: previewing and story state? [ In reply to ]
On Nov 21, 2008, at 7:59 AM, David E. Wheeler <david@kineticode.com> wrote:

>> So, I'm wondering why you couldn't do this:
>>
>> * Click preview from the story editing UI and pop up the frameset preview (which *is* super helpful when working on templates)
>> * Have the frameset refresh the main story editing screen after the preview is rendered
>
> This is the wrong solution to the problem. If you do this, any changes the user has made since the last change will be lost.

Six years later…

So, did I just kill this whole idea dead? Because, you know, the rejoinder to my critique here is that a "save and stay" could be made implicit in a preview. Maybe. If users don’t know it’s not saving, anyway. Did no one make a change like this to allow changes made from a template on preview to show up in the UI (story profile, desk, or workspace) after the preview?

Forget the context, old friends? It’s right here:

http://www.gossamer-threads.com/lists/bricolage/devel/35289

Asking for a friend.

Best,

David
Re: Comments re: previewing and story state? [ In reply to ]
On 2014-08-20, at 1:17 AM, "David E. Wheeler" <david@kineticode.com> wrote:

> On Nov 21, 2008, at 7:59 AM, David E. Wheeler <david@kineticode.com> wrote:
>
>>> So, I'm wondering why you couldn't do this:
>>>
>>> * Click preview from the story editing UI and pop up the frameset preview (which *is* super helpful when working on templates)
>>> * Have the frameset refresh the main story editing screen after the preview is rendered
>>
>> This is the wrong solution to the problem. If you do this, any changes the user has made since the last change will be lost.
>
> Six years later…
>
> So, did I just kill this whole idea dead? Because, you know, the rejoinder to my critique here is that a "save and stay" could be made implicit in a preview. Maybe. If users don’t know it’s not saving, anyway. Did no one make a change like this to allow changes made from a template on preview to show up in the UI (story profile, desk, or workspace) after the preview?
>
> Forget the context, old friends? It’s right here:
>
> http://www.gossamer-threads.com/lists/bricolage/devel/35289
>
> Asking for a friend.

I've not seen anything like that implemented. But, from watching users use Bricolage, I concur that most users think that hitting Preview saves the current state of the story (and it probably should).

Similarly, adding new elements to a story should probably also trigger a save.

Three cents,

Phillip.

--
Phillip Smith
http://phillipadsmith.com