About the sneak-preview (or live-preview):
1) The preview is refreshed periodically, and not anymore when clicking
outside the textarea element.
2) For v3.x, I'm working on a side-by-side view: so you will be able to see
the page preview next to the textarea.
A new button will allow you to switch between side-by-side or the
previous vertically-stacked view.
Additionally I was considering to allow the left-menu to be collapsed
(eg during edit) for an even wider view.
Anyway, I think it is key that the live-preview is shown in the same screen
as the editing. You get immediate feedback of the entered markup.
Additionally, I think it would be cool to also have a wysiwyg editor which
immediately 'previews' the wiki-markup ;-)
dirk.
On Sun, Feb 28, 2010 at 9:25 AM, Harry Metske <[email protected]>wrote:
> I agree on the Preview issue with you Andrew, in 2.8 the preview does
> require a lot of scrolling if your page is larger that half a screen.
> So let's keep the tab and rename it to preview .
>
> regards,
> Harry
>
> 2010/2/27 Andrew Jaquith <[email protected]>
>
> > A few comments and clarifications below...
> >
> > >> - I get many SPAM errors, even when I'm logged in. I should 'complete
> > the
> > >> challenge' but no challenge is presented.
> > >> Any cure for that ?
> > >>
> > >>
> > > I don't get them.
> >
> > I don't get them either, but I'd like to know what specific
> > circumstances trigger them for you. The default spam settings (right
> > now, at least) are very sensitive. A double-submit of a form, for
> > example could trigger the spam detectors because of the "one-time"
> > token we embed as a hidden form parameter.
> >
> > So, let me know what you do to make it happen, and I'll look into it.
> >
> > >> - During editing, I often get this message:
> > >> "When you save this page, we will use your profiles e-mail {0} instead
> > of
> > >> the cookie value {1}. If you want to use {1} instead, change the
> e-mail
> > >> address in your profile"
> > >> I've not seen this before.
> > >>
> > >
> > > Me too, looks like a bug
> >
> > This was an attempt on my part ensure that when the user submits a
> > page, the e-mail in their profile overrides any value they may have
> > set in their cookies. We *always* use the profile value -- the message
> > is meant to indicate that. However, I'm open to ideas on how to make
> > this more natural. Maybe just ignore the cookie value? Leave the
> > option to include an e-mail out?
> >
> > >> - ERROR.JSP has been moved inside the template, but mostly it is still
> > >> referred from the root.
> >
> > > me too, is a bug
> > >
> >
> > Whenever this happens, it is a bug. If it's in the JSP markup, that
> > markup should use the JSTL syntax "${templates['Error.jsp']}" rather
> > than "/Error.jsp". It's easy to fix, and if you encounter it I'd just
> > ask that you commit a fix. I'll look for these myself, although I
> > thought I'd eliminated them. This was a VERY recent change, so it is
> > likely there are a few instance of this kicking around.
> >
> > >>
> > >> - I noticed the "preview" functionality has been moved to the view
> tab,
> > >> while previously the live-preview was
> > >> immediately visible below or next to the textarea input field.
> > >> This requires an extra click if you wanna see the preview. I'd
> rather
> > >> keep the original approach.
> > >>
> > >
> > > +1
> >
> > I don't agree. The old sneak/live preview feature was pretty
> > non-intuitive. It required you to click somewhere ("anywhere") outside
> > of the textarea.
> >
> > The thought I had was this: if you have to click outside anyway to see
> > the page preview, why not just click on a TAB? I "re-used" the View
> > tab for this purpose... it essentially replaced the Preview.jsp from
> > the JSPWiki 2.8. I think, in general, that using clicking a tab for
> > previews is more natural because the rendered text has the same layout
> > as the page you are editing, rather than a "squeezed" layout on the
> > side, or below (which means lots of back-and-forth scrolling). Putting
> > it on its own tab seemed nice and clean, and it uncluttered the
> > editing interface.
> >
> > But, maybe we call the tab "Preview" instead to make the preview
> > feature more obvious. Or put it in a pop-up window like Wordpress
> > does.
> >
> > >>
> > >> Also the save button and change-note are moved back below the
> > edit-area,
> > >> as it was in old jspwiki versions.
> > >> Why go back ?
> > >>
> > >
> > > +1 for moving (or copying) it to the top
> >
> > The UI at the top of the page was very cluttered: it had the save
> > button, change-note, and toolbar. It seemed simpler and cleaner to
> > have it at the bottom.
> >
> > >> - The "Edit" link (in view context) is now positioned between view and
> > >> attachment.
> > >> Previous discussion on the position of the Edit link indicated that
> > this
> > >> was confusing may users.
> > >> Therefore it got positioned at the right of the screen was.
> > >> I suggest to keep that positioning as before.
> > >>
> > >>
> > > don't care, but if we earlier agreed to keep it right, we should do
> that
> >
> > I placed it next to "View" because of the preview change I made, as
> > discussed above. But maybe we could put it all the way to the right
> > (and add a Preview tab to the right of THAT). That would be fine with
> > me.
> >
> > FYI: one thing that you may note as you peruse the new template JSPs
> > is that I've deliberately broken up the tabs so that the "view"
> > feature (eg., Wiki.jsp) only loads the View tab; the other tabs link
> > to other JSPs e.g., PageInfo.jsp. That is deliberate -- I wanted to
> > make generating view pages fairly lightweight. But if a user clicks on
> > "Info" or "Attachments," then we load the other tabs and make them
> > clickable via JavaScript. The user won't notice the difference.
> >
> > >> - Viewing the raw content of a page is not working anymore.
> > >> Eg: http: ... /Wiki.jsp?page=<page>&skin=raw
> > >>
> > >>
> > > me too, looks a bug to me
> >
> > This is something I have not done yet. I didn't think it was needed
> > for the beta. I don't understand what the "raw" editor really does,
> > and I'm not really sure it is an "editor." What's the rationale for
> > this feature? If it is needed, then of course we need to get it
> > working. Whether we need it for Alpha, I don't know.
> >
> > >> - The <a class=external>..</a> external page link are still pointing
> the
> > >> /images/out.png.
> > >> /images have been moved inside the template.
> > >>
> > >>
> > >>
> > > hmm, I get this (isn't that correct) : <img class="outlink"
> > > src="/templates/default/images/out.png" alt="">
> > >
> >
> > If this occurs, it is a bug. Any code that generates links to
> > "standard" images should use TemplateManager.getResourceResolver() to
> > obtain the path to the image. I thought I caught all of these, but if
> > I didn't, please commit a fix.
> >
> > Andrew
> >
>
