Re: Post preview

[Michael C. Harris]

2009/5/21 David <david...@gmail.com>:
>
> I came to that conclusion after only trying out NicEditor 0.2.5,
> JWYSIWYG 0.3, and markUp 0.4.
>
> FWIW, a WYSIWYG editor is less important to me than the ability to
> easily preview the post and return to editing.  (If I had to choose.)

What would be your ideal for a preview ? I'm assuming you're saying
that the current preview isn't satisfactory for you ? Would you like a
preview on the publish page itself ? Something else ?

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari

[Andy C]

I'm interested.

I use 'Preview Post' a lot as my speeling isn't that grate.

I always use 'Preview Post' in a new tab, edit the post and keep
refreshing the Preview.

What do other folk do ?

On May 21, 1:47 am, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> 2009/5/21 David <david.bl...@gmail.com>:

[Michael C. Harris]

2009/5/21 Andy C <andy...@gmail.com>:

>
> I'm interested.
>
> I use 'Preview Post' a lot as my speeling isn't that grate.
>
> I always use 'Preview Post' in a new tab, edit the post and keep
> refreshing the Preview.
>
> What do other folk do ?

I do exactly that. Other ideas for more awesome are very welcome.

--

[Andy C]

Great minds think alike.

'Lover of Horses' just told me he also composes and previews posts
like this.

On May 21, 10:34 am, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> 2009/5/21 Andy C <andyc...@gmail.com>:

>
>
>
> > I'm interested.
>
> > I use 'Preview Post' a lot as my speeling isn't that grate.
>
> > I always use 'Preview Post' in a new tab, edit the post and keep
> > refreshing the Preview.
>
> > What do other folk do ?
>
> I do exactly that. Other ideas for more awesome are very welcome.
>
> --

[Alex Hempton-Smith]

Something like that would of-course update automatically without having to save each time, it would be relatively easy to do I think...

-- Alex

On Thu, May 21, 2009 at 1:13 PM, Alex Hempton-Smith <hemps...@googlemail.com> wrote:

Are people previewing their posts to see how they look in their template, or just how the image aligns etc. If its just for that, would a pop-up like this suffice?

http://is.gd/C01e

If, however, people need to see how it looks with their template it might have to be a pop-up with an iframe of their site?

-- Alex

[Alex Hempton-Smith]

Are people previewing their posts to see how they look in their template, or just how the image aligns etc. If its just for that, would a pop-up like this suffice?

http://is.gd/C01e

If, however, people need to see how it looks with their template it might have to be a pop-up with an iframe of their site?

-- Alex

[David]

On May 21, Alex Hempton-Smith <hempswo...@googlemail.com> wrote:
> Are people previewing their posts to see how they look in their template, or
> just how the image aligns etc. If its just for that, would a pop-up like
> this suffice?
>
> http://is.gd/C01e
>
> If, however, people need to see how it looks with their template it might
> have to be a pop-up with an iframe of their site?

I feel bad that an error on my part started this thread, but having
said that,
I'd have to preview content in the context of my template. So I
wouldn't bother
with the simpler popup.

--David

[David]

On May 20, "Michael C. Harris" <michael.twof...@gmail.com> wrote:
> 2009/5/21 David <david.bl...@gmail.com>:

>
> > FWIW, a WYSIWYG editor is less important to me than the ability to
> > easily preview the post and return to editing.  (If I had to choose.)
>
> What would be your ideal for a preview ? I'm assuming you're saying
> that the current preview isn't satisfactory for you ? Would you like a
> preview on the publish page itself ? Something else ?

Blame it on ignorance and the discoverability of the Habari entry-
writing workflow.

I had thought that the workflow was this:

1. Make changes and click the button "Save"
2. Quickly, before the transient log notice in the TL corner
disappears,
click the link in the log notice "... has been saved as draft."
If you missed it, you're SOL.
3. After previewing, hope that the browser's back button will bring
you back to the publish page with a populated form.

But when I saw that you wrote "the current preview" that made me
re-examine the publish page. Is there a workflow already in place?
Did I miss it?

It's only after careful examination and moving the mouse over all the
elements on the page that I noticed some static text that
stealthfully
appeared in the TR corner exactly when the TL corner drew my
attention
away. Like a pick-pocket team.

It was nicely executed sleight-of-hand that a magician would be proud
of.

I had no idea that "Preview Post" had appeared. I figured that it's
certainly
not a button or a link, because it doesn't conform to any of the style
cues
of the other clickable elements on the page.

Except that it is a link. If you ever discover it, and move your
mouse over it, then
you can discover that it's not static text, but a useful link that had
its
text-decoration set to none (as is consistent with the admin space),
but also
wasn't bold nor a button (and that's not so consistent).

Aha! OK. I can live with this workflow, now that I've found it.

I'd never seen Preview separated from Save and Publish quite like
that. It's separated
by distance on the page, visual style, and time of creation, even
though conceptually
it's somewhat related.

This is not a complaint. Merely an anecdotal story revealing why I
didn't discover
the preview mechanism. Something that might have helped me:

Transitioning from inactive (gray) to active instead of from invisible
to active. (I had
already scanned the publish page for links and controls before hitting
"save". I didn't
know I'd have to scan the page again for a newly created control after
hitting "save.")

--David

[Michael C. Harris]

2009/5/22 David <david...@gmail.com>:

> On May 20, "Michael C. Harris" <michael.twof...@gmail.com> wrote:
>>
>> What would be your ideal for a preview ? I'm assuming you're saying
>> that the current preview isn't satisfactory for you ? Would you like a
>> preview on the publish page itself ? Something else ?
>
> Blame it on ignorance and the discoverability of the Habari entry-
> writing workflow.

It was a completely serious question; if it's not clear, maybe we can
make it clearer :)

[snip excellent feedback]

> Transitioning from inactive (gray) to active instead of from invisible
> to active.  (I had already scanned the publish page for links and controls before hitting
> "save".  I didn't know I'd have to scan the page again for a newly created control after
> hitting "save.")

That sounds reasonable to me.

I think there's also probably room for an iframe in-page preview
plugin. Personally, I agree with David, I want to see it in my
template.

[Arthus Erea]

I'm not sure how we would have the "preview" button appear before
saving. As it is, there has to be some data in the post to preview or
the theme has nothing to look at.

I feel strongly we shouldn't have elements which do, well, nothing.
Also, it might create the mistaken impression that you can "preview"
as your work—that is, before you save.

I think the best solution is twofold:
1) Maintain the current "preview" link for full-page preview
2) Create a plugin which allows a preview tab (next to settings),
which when clicked, will pull up a live preview.

I feel fairly strongly that the preview *shouldn't* block out the edit
form, because otherwise isn't much more useful than the current
method. You should be able to type in the edit form while having
changes immediately mirrored in the tab preview.

[David]

Arthus Erea <arthus.e...@gmail.com> wrote:
> I'm not sure how we would have the "preview" button appear before  
> saving. As it is, there has to be some data in the post to preview or  
> the theme has nothing to look at.

As it is, there doesn't have to be any data (as the user defines
data). One can already start a new post, without typing anything, hit
save and preview, and see a preview of an "empty" post. Works just
fine.

Suppose that "preview" were always present and active. (And would
display the same silly empty post that it currently does after you've
"saved" nothing.) What you would gain is the additional
discoverability of the button when the page is first loaded. (Small
gain though it is.)

The downside, though, as Arthus points out, is that it does nothing of
particular value at that point, except to demonstrate its presence and
expected function when data eventually gets entered. The downside
might outweigh the upside even in my own eyes. I'm undecided, and
leave it to those of you with actual user-experience experience.

After some consideration, I might vote against my own naive idea:

David wrote:
> Transitioning from inactive (gray) to active instead of from invisible
> to active. (I had already scanned the publish page for links and controls before hitting
> "save". I didn't know I'd have to scan the page again for a newly created control after
> hitting "save.")

Since the link's style is text-decoration: none, then an "inactive
(gray)" version of it might be indistinguishable from simple static
text. Unless it changed its wording from "Cannot Preview Yet" to
"Preview Post", then the mere subtle change from inactive to active
(gray to black) would probably be missed. Why would I suspect what-I-
originally-took-to-be-static-text would turn into a working link?
That's probably even *more* subtle the the appearing link I was
complaining about.

Habari's user experience is already very well designed, and I can see
the reasoning behind it. Just because I happen to have an anecdotal
story about the downside of one of the tradeoffs doesn't mean that
it's the *wrong* tradeoff. I appreciate that you're open to the
discussion, though.

Thanks,
--David

[Arthus Erea]

This definitely is an issue and thanks for bringing it up.

I'm still against including anything for unsaved posts, since I don't think we should have text just saying something you can't do.

However, the preview link should probably be highlighted better. Primarily:

1) It should look like a link (possibly underlined?)

2) When it becomes available, it should be highlighted briefly with color.

On May 22, 2009, at 2:27 AM, David wrote:

Arthus Erea <arthus.e...@gmail.com> wrote:

I'm not sure how we would have the "preview" button appear before  

saving. As it is, there has to be some data in the post to preview or  

the theme has nothing to look at.

As it is, there doesn't have to be any data (as the user defines
data).  One can already start a new post, without typing anything, hit
save and preview, and see a preview of an "empty" post.  Works just
fine.

Right, but from a technical standpoint we'd have nothing to link to. Since there's no post and no ID in the database, we can't create a preview link.

~Arthus

[Chris J. Davis]

Right, this is an important issue to bring up as others have said. I have long been annoyed by the preview link but didn't have a better solution in mind that did not enter the realm of ham-fistedness.

At the very least we should have the text be more recognizable as a link, and I think Arthus's suggestion of a brief highlight of color upon being added to the page is a good first step in making it much more useable.

[Owen Winkler]

Chris J. Davis wrote:
> Right, this is an important issue to bring up as others have said. I
> have long been annoyed by the preview link but didn't have a better
> solution in mind that did not enter the realm of ham-fistedness.
>
> At the very least we should have the text be more recognizable as a
> link, and I think Arthus's suggestion of a brief highlight of color upon
> being added to the page is a good first step in making it much more useable.

Just change the Preview link to a button and move it to the line with
the Save/Publish/Delete buttons.

You could even have it prompt you to save changes first, so if it shows
up on the initial drafting page, it would first save and then preview.

See:
http://screencast.com/t/HrT3JfjH

Owen

[Chris J. Davis]

I really like it in the top corner though. That placement gives you
higher visibility. I don't want to have to scroll to find the preview
button, it should just be there.

[Owen Winkler]

Chris J. Davis wrote:
> I really like it in the top corner though. That placement gives you
> higher visibility. I don't want to have to scroll to find the preview
> button, it should just be there.

Yeah, but if you read the initial story of how all this started, the
reason he didn't see it in the first place is because it wasn't where
all of the other controls were.

Personally, I want to rid the admin of all the FAT links, especially the
inline comment editing. I don't want to add more.

Owen

[Arthus Erea]

Conceptually, I am against moving the preview link into a button at the bottom.

The bottom buttons are actions. When you click them, they do something to the post:

1) Publish it

2) Save it

3) Delete it

In contrast, previewing just changes your view of the post. It doesn't do anything to the actual post.

I don't think the bottom is the right place for the preview link. It doesn't make conceptual sense and also seems hard to access.

What is a FAT link? Are you just emphasizing fat?

[Owen Winkler]

Arthus Erea wrote:
> Conceptually, I am against moving the preview link into a button at the
> bottom.
>

> The bottom buttons are /actions/. When you click them, they do something

> to the post:
> 1) Publish it
> 2) Save it
> 3) Delete it

Right. You need to save a post to preview it.

Did you watch the movie? It makes you save before the preview happens.
It's potentially not apparent that something like the existing link
won't preview any changes that you've made unless you've already saved
your post.

Also note, as I was saying before, that if it is a button in the action
area and it saves your post on click, then you can use it to
save-and-preview rather than having to click save first. This was a
specific request earlier in the thread.

>
> What is a FAT link? Are you just emphasizing fat?

Fade Anything Technique.
http://www.google.com/search?q=fade%20anything%20technique

Owen

[Arthus Erea]

Saving a post is an action taken upon a post. We already have a button
to do said action.

Previewing is something you can do with a post, but it does not affect
the post at all. The buttons at the bottom are for updating a post;
previewing is just "getting" a post.

I think having the save prompter makes sense, and would be happy to
implement it in the current link.

In fact, that's probably the best solution:
1) Keep the current link position, but always have it there.
2) If clicked for an unsaved post, prompt to save first.

In that situation, I don't see any need for FAT and recommend against
using it.

~Arthus

[David]

I agree with Arthus.

The buttons perform actions, while links navigate you elsewhere.
We're
using the right controls.

My issue was a matter of discoverability. Arthus's recommendation
below would have led to an improved user experience for me.

--David

[Shawn J. Goff]

I completely disagree. I also assumed there was not yet a preview
function implemented. I looked to the bottom for "things I can do
related to this post", not for "things that will affect this post".
The link with the rest of the functions, and it should look the same.
Additionally, this is done in many other systems, so many users
already have the habit of looking there (with the rest of the
functions) for a preview.

I think the excuse for not placing it there is due to hyperanalysis.