On Mon, Jun 25, 2012 at 2:44 PM, Guillaume Lerouge <[email protected]>wrote:
> Hi, > > this looks like a lot of complex things to do for an result that will not > be user friendly. > > First, I don't really thing we want users to put styles, links or wiki > macros in titles. The "Title" is just that, a pretty name for the page. I > don't know any web application that handles the title as anything else than > a simple, one-line-long input field. Handling it differently is going to > create a lot of confusion for users. > I happened to stumble upon one use case where I wanted markup in my titles : for "sub-titles". See for example headings at http://twitter.github.com/bootstrap/base-css.html ; where they wrap sub-titles in <small> tag. But I agree there aren't many legitimate use case for markup in titles. Though it doesn't mean it cannot be exposed through a stripped down WYSIWYG, in my opinion. I like the idea Vincent presented of a one-line textarea that expand when you type enter, same way the facebook message box works. But one thing is certain, should we go for the WYSIWYG it HAS to be a stripped down WYSIWYG, with just the a very minimal set of buttons. One idea could be to have the "Source" button only for advanced users. > > We could make entering the title mandatory to make sure there's always one, > and thus remove the need to compute it from the content of the page. If the > title is not given (due to a script creating a page), it could > automatically be filled with the page name when the page is created. > Yes ideally when creating a page, the title should be copied from what the user typed in to create the page in the "page name" box, this whatever the rule is to create the final page name. This is what wordpress and many other tools do. I think a corollary for clarity and ease of use would be to introduce the "page name" as the "permalink" notion, which users are often familiar with ; this in the rename dialog for example. See also what I've experimented with in Lyrebird : http://extensions.xwiki.org/xwiki/bin/download/Extension/Lyrebird+Skin/lyrebird2.png. An other idea for the rename dialog in future versions could be to have options for generating 3xx redirect aliases. > Second, applications that need it would be responsible to compute the right > title for any page based on data entered by the user and would feed it to > the title field upon saving the page. > Yes this is often the right solution for such applications. It has the advantage to make the title searchable, filterable in livetables, etc. > > Third, we already have a mechanism to handle internationalized content in > wiki pages - the translations of that page in other languages when in > multilingual mode. > Yes, although this mechanism is awkward and personally I've never seen any real use of it, besides our packaging of translated Main.WebHome and Sandbox space... > > Right now, it feels like we're about to try to implement something very > complex for the sake of making developer's live a bit easier, while at the > same time sacrificing ease-of-use in a very big way. This is not something > that I feel will benefit XWiki in the long run, whether for users or for > devs. > > If we want to change the way the title works, I'd like us to *start with a > list of use cases* and see *how the proposed solution impacts them and > makes them better.* > I agree it's a touchy subject and we have to make it right. Jérôme > Thanks, > > Guillaume > > On Mon, Jun 25, 2012 at 1:01 PM, Anca Luca <[email protected]> wrote: > > > On 06/25/2012 12:22 PM, Eduard Moraru wrote: > > > >> On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca <[email protected]> wrote: > >> > >> On 06/25/2012 10:59 AM, Eduard Moraru wrote: > >>> > >>> Hi, > >>>> > >>>> On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol <[email protected]> > >>>> wrote: > >>>> > >>>> Hi guys, > >>>> > >>>>> Some time back we started improving title handling, I'd like that we > >>>>> continue this and I'm proposing some further improvements below: > >>>>> > >>>>> * Make the title field contain wiki syntax (same as the content > field) > >>>>> instead of just velocity > >>>>> > >>>>> I am not a big fan of seeing code (of any kind) in titles. IMO, it > is > >>>> bad > >>>> practice and we should discourage people from doing it. You have lots > of > >>>> problems when some application lists the titles of pages with code in > >>>> their > >>>> title or, worse, when the application tries to render those titles. > You > >>>> have all sorts of security issues and generally bad things when the > >>>> writer > >>>> of that title does not assume that it is going to be rendered outside > >>>> his > >>>> page. I know it is a cool feature, but it is causing too much headache > >>>> to > >>>> handle correctly. > >>>> > >>>> AFAIK, 90% of the times when we need the title to be rendered is > because > >>>> we > >>>> need translation keys. We could very well have a filtered wiki syntax, > >>>> that > >>>> allows only calls to the new {{translation}} macro. > >>>> > >>>> As Thomas said, there are cases when something else is used (with > >>> velocity > >>> code, yes). Now this something else might indeed be only 10% of the > >>> cases, > >>> but we should still keep it possible. Not show it in the UI because 90% > >>> of > >>> the people don't care about it, but still keep it possible. > >>> > >>> > >>> Can you please give me some examples where this feature is essential > to > >> the > >> functionality/user experience of an application? (also please see my > reply > >> to Thomas' comment). > >> > > > > 2 typical cases: > > 1/ you have a text in a property in an object in the document and you > want > > that text to be displayed as the document title. For various reasons, > this > > text cannot be in the document title field itself or in the document name > > (it's not unique, it's not short enough, the text is actually part of the > > type structure and the structure would be incomplete if you put the data > in > > the title since title is not semantic (it just means document title it > > doesn't mean "frequently asked question" in a FAQ application, for > example > > ), you don't want to duplicate texts (once in a prop once in the title), > in > > enough cases it's wrongly used by devs that don't think about using > titles > > and re-add a property -- also because http://jira.xwiki.org/browse/** > > XWIKI-7905 <http://jira.xwiki.org/browse/XWIKI-7905> --, etc) > > 2/ indeed you want to decorate the title: e.g. for the search, you want > to > > display the searched word in the title; you have a page with scripted > > content that lists all documents for a tag, or for some property, you > want > > the title to be different depending on what that tag is or the property > > Also: > > 3/ We need 1/ and 2/. Indeed they might be just bells and whistles but we > > need them to provide nice things and we want these nice things. Not > having > > them will not stop from providing nice things, it will only lead to > hacking > > it: customizing .vms to hide the title and then putting it with hacked > html > > and css from the document content (i've seen it done), or even > customizing > > it directly in the .vm. > > > > As I said in one of my previous mails, I think it's only for devs, a lot > > less for users. So we don't need to show it, for the users the title > should > > stay simple, but all these things need to stay possible since otherwise > > everybody will customize by its own mean, more or less correct, in 80% of > > cases (for devs, I repeat). > > > > Thanks, > > Anca > > > > > > > >> Thanks, > >> Eduard > >> > >> > >>> An alternative to people that *really* want to generate their title > >>>> trough > >>>> a script is to actually keep the title extraction from the document > >>>> content > >>>> and make them have to generate a <h1> element from the content, not > from > >>>> the title. This means that they have to leave the actual title empty > for > >>>> the extraction to be triggered and, if I am not mistaken, applications > >>>> that > >>>> want to list document titles can use > >>>> api.Document.gerRenderedTitle(****document.syntax.toIdString()**) (as > >>>> they > >>>> probably did before) and the first heading (that is either static or > >>>> programmatically generated) > >>>> > >>>> No, not programatically generated. Last time I checked, title > >>> extraction > >>> tool was not evaluating scripts. > >>> Also this extraction thing is really crap because it's hard to use: it > >>> uses a hack to not display the title twice, which is to search for the > h1 > >>> with a regex (aaaaaa!) in a vm to put a hidden class so that it's not > >>> displayed. This makes it terribly painful to re-use those title and > >>> content > >>> somewhere else since you don't know if you'll have 2 titles or just one > >>> (in > >>> a pdf export, for example). > >>> > >>> Thanks, > >>> Anca > >>> > >>> > >>> will be displayed, which sounds good to me. > >>> > >>>> So I would be +1, considering the comment above (restricted use of > >>>> macros). > >>>> > >>>> > >>>> * Make the title field a textarea so that we can have more than 1 > line > >>>> > >>>>> * Display a textarea of 1 line initially (to preserve space) but > >>>>> enlarge > >>>>> the textarea visibility by several line on the first Enter keypress > in > >>>>> the > >>>>> field > >>>>> * Stop trying to extract title content from the doc content > >>>>> > >>>>> +1 > >>>>> > >>>> > >>>> * Have a backward compat param to still support the old mode, but > have > >>>> it > >>>> > >>>>> off by default in 4.2/4.3 > >>>>> <side> > >>>>> * Introduce a {{i18n}} macro (or {{translate}}, or …) > >>>>> > >>>>> +1 > >>>>> > >>>> > >>>> </side> > >>>> > >>>>> Advantages: > >>>>> * Same as the content field - More consistency > >>>>> * More power since we use wiki syntax and we can use any script > >>>>> language > >>>>> > >>>>> More problems for devs, more raised eyebrows from users. :) > >>>>> > >>>> > >>>> * Removes the WTF symptom when a user edits a page having velocity > >>>> script > >>>> > >>>>> in the title since they'll see it displayed in WYSIWYG mode with the > >>>>> title > >>>>> content evaluated > >>>>> * Removes the uncertainty about title extraction (for ex if some > macro > >>>>> generates headings) but still allow it if it's really needed - Since > >>>>> the > >>>>> user will be able to write scripts in the title textarea and those > >>>>> scripts > >>>>> can extract stuff from the doc content if they really need it > >>>>> * We'll be able to add a l18n macro and thus display the title > >>>>> translations nicely in the wysiwyg editor > >>>>> > >>>>> WDYT? > >>>>> > >>>>> Thanks > >>>>> -Vincent > >>>>> > >>>>> ______________________________****_________________ > >>>>> devs mailing list > >>>>> [email protected] > >>>>> http://lists.xwiki.org/****mailman/listinfo/devs< > http://lists.xwiki.org/**mailman/listinfo/devs> > >>>>> <http://**lists.xwiki.org/mailman/**listinfo/devs< > http://lists.xwiki.org/mailman/listinfo/devs> > >>>>> > > >>>>> > >>>>> ______________________________****_________________ > >>>>> > >>>> devs mailing list > >>>> [email protected] > >>>> http://lists.xwiki.org/****mailman/listinfo/devs< > http://lists.xwiki.org/**mailman/listinfo/devs> > >>>> <http://**lists.xwiki.org/mailman/**listinfo/devs< > http://lists.xwiki.org/mailman/listinfo/devs> > >>>> > > >>>> > >>>> > >>> ______________________________****_________________ > >>> devs mailing list > >>> [email protected] > >>> http://lists.xwiki.org/****mailman/listinfo/devs< > http://lists.xwiki.org/**mailman/listinfo/devs> > >>> <http://**lists.xwiki.org/mailman/**listinfo/devs< > http://lists.xwiki.org/mailman/listinfo/devs> > >>> > > >>> > >>> ______________________________**_________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/**mailman/listinfo/devs< > http://lists.xwiki.org/mailman/listinfo/devs> > >> > > > > > > ______________________________**_________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/**mailman/listinfo/devs< > http://lists.xwiki.org/mailman/listinfo/devs> > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
