Re: [xwiki-devs] Home Page - Use cases, proposals, what we have until now and what we want to achieve

6 Nov 2014

On 6 Nov 2014 at 12:58:48, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:

...
  We had this discussion one year ago with Vincent. He
wanted to go in the
 direction where everything is an application with a proper UI and not
 necessary in the administration. 
Some points on this to be clear:

1) Indeed for discoverability I think it's good to have application features visible
in the app themselves whether it’s for end users, developers or admins. For example the
fact that in the Wiki Index, you can have an “Edit Descriptor” button if you’re an admin
of that wiki, or the fact that in the AllDocs livetable page, you can delete a doc if you
have the permissions. Basically you see actions that you have the right to perform.

2) Regarding configuration of apps, I agree that the best place is the Administration with
sections for each app. What I didn’t want to have is to force the users to be admin to be
able to access applications. For example at the time the discussions were about the
Scheduler app, the Statistics app just to name 2. It was proposed that they be
visible/findable only from the Admin screens and that’s what I didn’t like. In the end
I’ve made them visible/discoverable by listing them in the Application Panel when the user
has admin rights.

3) Wiki descriptors are about configuration and I would find it normal and good to have
them in the Main wiki’s administration screens too. This means they could be accesssed
both from the Wiki index screen ( point 1) above) and from the Admin UI (point 2) above).

Thanks
-Vincent

...
  Moreover, it is very important to be able to modify a
descriptor from the
 main wiki instead of the subwiki, since if you break it, you might be
 unable to access your subwiki anymore!

 2014-11-06 11:10 GMT+01:00 Marius Dumitru Florea <
 mariusdumitru.florea(a)xwiki.com&gt;gt;:

  On Thu, Nov 6, 2014 at 11:00 AM, Eduard Moraru  
 wrote:

  The problem with the current place is that it is
not really natural and
 thus not very discoverable at all. 
 I have this feeling to. I wanted to edit the descriptor of a subwiki a
 few days ago and I was surprised I could find anything related in the
 subwiki administration.

  If you have to set the homepage, owner,
 etc of your wiki, you go to administration, but never to "wiki index > 
edit
  wiki".

 I believe that along this thread we have identified that these settings  are
  valuable for both the main wiki and subwikis so
this makes editing the  wiki
  descriptor a valuable and deserving section to be
introduced in
 administration, don`t you agree?

 Thanks,
 Eduard

 On Wed, Nov 5, 2014 at 4:38 PM, Guillaume "Louis-Marie" Delhumeau <
 gdelhumeau(a)xwiki.com&gt; wrote:

> 2014-11-05 14:43 GMT+01:00 Eduard Moraru :
>
> > Concerning UC3 and UC4, we should not re-invent the wheel. I have just
> > remembered about the fact that we already have the option of setting  the
 > > homepage of a wiki exposed in the
wiki's descriptor, so this makes is
> > already configurable.
> >
> > All we need to do now, is to expose this configuration further, in
> > Administration > Configuration, under Wiki section (just like it was 
for
 > > workspaces, no idea why we removed it
when refactoring to 'wikis'),
>
>
> About this setting in particular it is because it is part of the wiki
> descriptor, and we now have only one place to edit these properties.
>
>
> > where
> > you can select what is the homepage of your current wiki. Selecting  the
 > > owner and basically all the other stuff
that you have in a wiki
> descriptor
> > should be done at this same level, since these are very important
> > configurations that one needs to perform for either his main wiki or
> > subwiki.
> >
> > And no, the xwiki-platform-wiki module is not optional (it is part of 
the
 > > wiki model!), so no point in using a
configurable class and throwing  it
 > > back in the 'Applications'
section.
> >
> > This actually goes along the lines of 'Proposal4: Set this page as
> > homepage' [1], but done in Administration, not on every page, like
> Vincent
> > suggested.
> >
> > To get the homepage, apps need to do:
> > $services.wiki.getById($services.wiki.currentWikiId).mainPageReference
> > Of course, this can be improved to
> > $services.wiki.currentWikiDescriptor.mainPageReference
> >
> > We will be still having the backwards compatibility concerns of P4,
> however
> > I am sure that practical solutions (e.g. making Main.WebHome redirect  to
 > > 
$services.wiki.getById($services.wiki.currentWikiId).mainPageReference,
 >> > etc.) can be found if problems arise in daily use.
 > >  >> > WDYT?
 > >  >> > ----------
 >> > [1]
 > > 
 > >  >>
 http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal4Setthispag…
 > >  >> > On Wed, Oct 29,
2014 at 6:10 PM, Jeremie BOUSQUET <
 >> > jeremie.bousquet(a)gmail.com&gt; wrote:
 > >  >> > > Hi,
 >> > >
 >> > > 2014-10-28 21:08 GMT+01:00 vincent(a)massol.net :
 >> > >
 >> > > >
 >> > > >
 >> > > >
 >> > > >
 >> > > >
 >> > > > On 28 Oct 2014 at 20:28:15, Jeremie BOUSQUET (
 >> > jeremie.bousquet(a)gmail.com
 >> > > > (mailto:jeremie.bousquet@gmail.com)) wrote:
 >> > > >
 >> > > > > Hi,
 >> > > > > Le 28 oct. 2014 19:39, "Eduard Moraru" a écrit :
 >> > > > > >
 >> > > > > > Hi Vincent,
 >> > > > > >
 >> > > > > > On Mon, Oct 27, 2014 at 11:05 AM, vincent(a)massol.net
 >> > > > > > wrote:
 >> > > > > >
 >> > > > > > > Hi,
 >> > > > > > >
 >> > > > > > > On 24 Oct 2014 at 21:18:31, Eduard Moraru (
 >> enygma2002(a)gmail.com
 >> > > > (mailto:
 >> > > > > > > enygma2002(a)gmail.com)) wrote:
 >> > > > > > >
 >> > > > > > > > Hi,
 >> > > > > > > >
 >> > > > > > > > 2 new proposals (P6 and P7) have been made
recently. I did
 >> not
 >> > > yet
 >> > > > get
 >> > > > > > > the
 >> > > > > > > > chance to add comments/analysis on them. Feel
free to do
 it
 > in
> > > the
> > > > > > > > meanwhile if anybody wants to.
> > > > > > > >
> > > > > > > > A few notes on Jeremie's "Proposal7:
DistrbutionWizard  sets
 > the
> > > > > homepage
> > > > > > > of
> > > > > > > > a flavor and the Help App teaches users"
[2]:
> > > > > > > >
> > > > > > > > Personally, I find it a rather elegant solution
based on
> > > > separation of
> > > > > > > > concerns. However, you need to be aware that it is
a
> > medium/long
> > > > term
> > > > > > > > objective.
> > > > > > > >
> > > > > > > > The way I understood it is that we delegate the
task of
> > choosing
> > > a
> > > > > > > homepage
> > > > > > > > to the DistributionWizard that will most likely be
in  charge
 > of
> > > > > offering
> > > > > > > > the user flavor options. At that point, the
homepage of  the
 > > > current
> > > > > wiki
> > > > > > > > will be the homepage of the user selected flavor.
 Optionally,
 > > we
> > > > can
> > > > > also
> > > > > > > > propose to use a blank page as homepage if the
user wants,
> > > however
> > > > > this
> > > > > > > > might be a bit of an overkill, since the user can
easily  edit
 > > the
> > > > page
> > > > > > > and
> > > > > > > > trash everything.
> > > > > > >
> > > > > > > The DW should not know at all about any page. It should
be  up
 > to
> > > the
> > > > > > > flavor to define the wiki pages it will contain and
install.
> Each
> > > > flavor
> > > > > > > should propose its own home page.
> > > > > > >
> > > > > >
> > > > > > Maybe I did not choose the best words, but the way I 
understood
 > it
> > > (and
> > > > > > tried to reformulate it) was not that the DW explicitly
allows
> you
> > to
> > > > > > select a homepage, but that indirectly, through allowing you
 to
 > > > > install a
> > > > > > flavor, it will additionally do the job (again, indirectly)
of
> > making
> > > > you
> > > > > > choose a homepage (through the flavor you have selected).
> > > > >
> > > > > Yes that was the idea, possibly:
> > > > > - DW doesn't have to know pages or set homepage
> > > > > - there could be a new wizard, similar to wizards for new page /
> > space
> > > > from
> > > > > template, that allows choosing a kind of homepage (empty, wiki
> > > concepts,
> > > > > dashboard, etc)
> > > > > - a flavor also adds its homepage as a possible
"template"
> > > > > - btw it could be exactly the new space from template page, but
> with
> > > more
> > > > > choices than current (empty / dashboard)
> > > > > - following a dw run and a flavor installation, this "new
Main
> space
> > > > > homepage from template" wizard is triggered and displayed
(or  just
 > > > > proposed
> > > > > to user through a button or link), and allows user to either
 choose
 > > > > default
> > > > > homepage of the flavor, or use another one
> > > > > - current (or reworked) homepage is just the default home of the
> > > default
> > > > > flavor (which is the current XE xar)
> > > >
> > > > ok but:
> > > >
> > > > 1) it’s complex since it means that a flavor would need to 
register
 > > some
> > > > kind of post install script to execute (which is something we 
don’t
 > > > really
> > > > have)
> > > >
> > >
> > > Depends, I was thinking more about a specific event like "flavor
> > installed"
> > > or "extension installed" or "wiki installed / updated".
I'm not  sure to
 > > get
> > > what you would need to do in this post install script ?
> > > But it could be completely "manual" or just a link at the end of
DW  to
 > > some
> > > possible post-install stuff (like, consult help, manage home page,
> etc).
> > >
> > > I'd like to apologize here because my "proposal" was more an
idea  than
 > a
> > > well formalized proposal, even if it ended up in the list of 
proposals,
 > > > it's obvious that it misses
some thoughts and clarifications... (I
> > > understand your -1).
> > >
> > >
> > > > 2) it negates a bit the point of a flavor which is to propose a
> defined
> > > > “theme” and thus a defined home page matching that theme
> > > >
> > >
> > > Well, if you consider that current UI of XE is the default xwiki
> > "flavor",
> > > this is exactly what it's about when we talk about switching home
 page
 > > > easily, isn't it ? We want to
let user set a home page that doesn't
> match
> > > the default theme freely. Obviously this default theme is not very
> > > "thematic" as it's the default and should be versatile ...
> > > Home page matching that theme could still be the mostly recommended
> > choice.
> > > BTW a flavor, with such mechanism, could provide several "home
page"
> > > variants and not only one, depending on the case.
> > > If I take the case of a flavor based on the Mail archive (or the 
mail
 > > > archive extension alone, say), it
already provides different views  as
 > the
> > > app home page (timeline, livetable, etc). Currently the switch is 
done
 > > > through conditional include.
Currently that app home page is
> > > MailArchive.WebHome, if I could register it as a possible home page
> > > template, it would avoid having to rename it "Main.WebHome" to
make  it
 > a
> > > flavor (and potentially destroy existing wiki home page by mistake 
when
 > > you
> > > install that extension/flavor), and I could fullfill both 
installation
 > > > use-cases (of using it as an app
among others in some wiki, and as a
> > > wiki-wide-flavor in another wiki or subwiki), from the same xar 
bundled
 > > > app.
> > > Again, here, I talk about possibilities and use-cases that seem 
logical
 > > or
> > > interesting to me if I dig into my proposal, but I really don't 
know if
 > > > it's a good path or even a good
idea for xwiki - I may not have the  big
 > > > picture :)
> > > Also, the proposal certainly does not offer any solution for 
short-term
 > > (if
> > > you consider it provides options for long-term ;-) )
> > >
> > >
> > > > 3) it doesn’t solve anything since once you select a default 
homepage
 > > you
> > > > still need a way to change it afterwards if you want to change it…
> > > >
> > >
> > > There was the side-idea of the proposal (not well formulated, maybe 
was
 > > > just in my mind) that this wizard
and/or DW could be triggered at  any
 > > later
> > > time by an admin if he wants to replace homepage with some other
> > "default"
> > > content. Maybe could be seen as a "personalization" step
following a
> new
> > > wiki install or upgrade, but that could be triggered at any later 
time
 > to
> > > "re-personalize" his wiki. I would put this then also as a
feature  in
 > > admin
> > > UI.
> > > The difference with some other proposals, is that it would not be an
> > action
> > > available from the standard UI but limited to a post-install step 
and
 > the
> > > admin UI (not like the variant below).
> > >
> > >
> > > >
> > > > I don’t see how this is much better than having a Admin UI 
allowing
 > you
> > > to
> > > > change the home page you wish to have. However it’s a lot more
> complex
> > > (and
> > > > really marginally better).
> > > >
> > > > > Maybe instead of all this, it could be enough to unrelate the
 "new
 > > > space"
> > > > > and "apply space homepage template" features ?
> > > > > So I would just have to call "space / apply template"
to replace
> the
> > > > > homepage of any space already existing (including Main 
obviously) ?
 > > > >
> > > > Yes that’s better already IMO but then it should be a menu option
 to
 > > > > replace any page content with
a page template.
> > > >
> > >
> > > I'm not sure if you talk about an additional option, or an option
 that
 > > > would replace the "space
/apply template" by a more generic "page /
> apply
> > > template", but I don't think anyway that a page template is the
same
> > thing
> > > as a home page template (whether it's a space or wiki home page).
 You'd
 > > > seldom want to use a blog post as a
home page ...
> > >
> > > In this variant, there's still the question, if applying such 
template
 > is
> > > considered an admin operation or not. If it's an admin operation,
 you
 > > also
> > > proposed to start moving those admin actions to the admin UI, which 
is
 > -
> > > sort of - what was my proposal about in first place :) (I didn't 
talk
 > > > specifically about admin UI at that
time, but about avoiding to  crowd
 > > > standard UI menus with
unfrequent/admin operations).
> > > That being said I don't think it's an admin action, if you need to
> > protect
> > > home page, as an admin you can set specific rights and forbid this
> "apply
> > > template" to people that don't have those edit rights. I'm not
sure
> > editing
> > > home page and applying a template should really be different in 
terms
 > of
> > > privileges. But applying a template on an existing page or home 
page,
 > > seems
> > > to be a rather unfrequent operation.
> > >
> > >
> > > >
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > > > > It was just a high level view on the direction to follow,
and
> not a
> > > > > > specific technical aspect, so no reason to -1 it, right?
> > > > > >
> > > > > >
> > > > > > > BTW there’s also another variation for the home page
that
> hasn’t
> > > been
> > > > > > > discussed yet:
> > > > > > > * Make the home page special by not making it editable
(and
> > without
> > > > any
> > > > > > > docextra tabs at the bottom). So no rollback
issue/edit
> > weirdness.
> > > > > > > * Only admins can change it and only through the Admin
UI
> > > (basically
> > > > > > > decide which space home page to display on the wiki
home  page).
 > > > > > > > * Somewhere in
the content of the default home page or  through
 > > the
> > > > first
> > > > > > > time wizard, direct the users to the Sandbox page to
try it  out
 > > > > editing
> > > > > > > (since this is what Sandbox is for!)
> > > > > > >
> > > > > >
> > > > > > Adding this too and I think we`re good for going forward
with  a
 > > vote,
> > > > > since
> > > > > > we have plenty of proposals.
> > > > > >
> > > > > > Thanks,
> > > > > > Eduard
> > > > > >
> > > > > > >
> > > > > > > Thanks
> > > > > > > -Vincent
> > > > > > >
> > > > > > > > The task of teaching the user is delegated
exclusively to  the
 > > > Help
> > > > > > > > Application, with the note that the application
will also  be
 > > > > proposed
> > > > > to
> > > > > > > > the user to be redirected to, as a final step in
the DW
> (after
> > > the
> > > > > > > > installation of the user selected flavor is
complete).
> > > > > > > >
> > > > > > > > All of this assumes that we have a properly
working  Flavors
 > > > feature
> > > > > and
> > > > > > > > Help Application. However, what should we do in
the  meanwhile
 > > for
> > > > the
> > > > > > > > default XWiki Enterprise UI / Flavor / build?
Should we
> > postpone
> > > > yet
> > > > > > > again
> > > > > > > > any work on the homepage until we have the needed
 elements to
 >> > > > delegate
 >> > > > > > > the
 >> > > > > > > > problematic aspects, or should we do
something about it in
 >> the
 >> > > > > meanwhile?
 >> > > > > > > >
 >> > > > > > > > Thanks,
 >> > > > > > > > Eduard
 >> > > > > > > >
 >> > > > > > > > ----------
 >> > > > > > > > [1]
 >> > > >
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals
 >> > > > > > > > [2]
 >> > > > > > > >
 >> > > > > > >
 >> > > > >
 >> > > >
 >> > >
 > >  >>

http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal7Distrbutio…
 > > > > > > > >
> > > > > > > > On Tue, Oct 14, 2014 at 12:40 PM, Guillaume
"Louis-Marie"
> > > > Delhumeau <
> > > > > > > > gdelhumeau(a)xwiki.com&gt; wrote:
> > > > > > > >
> > > > > > > > > Hello.
> > > > > > > > >
> > > > > > > > > I have again a new argument against using the
dashboard  and
 > > the
> > > > > include
> > > > > > > > > macro in the main page.
> > > > > > > > >
> > > > > > > > > When the user uses the "Inline"
editor to change some
> > gadgets,
> > > > she
> > > > > can
> > > > > > > not
> > > > > > > > > use the rollback action of the main page to
cancel her
> > changes.
> > > > She
> > > > > > > has to
> > > > > > > > > go to the Dashboard page first, and then
rollback her
> changes
> > > > from
> > > > > > > there.
> > > > > > > > >
> > > > > > > > > Having an include macro in the default page
is  absolutely
 >> not
 >> > > > > > > intuitive,
 >> > > > > > > > > even if you make it appears more
clearly.
 >> > > > > > > > >
 >> > > > > > > > > Thanks,
 >> > > > > > > > > Guillaume
 >> > > > _______________________________________________
 >> > > > devs mailing list
 >> > > > devs(a)xwiki.org
 >> > > > http://lists.xwiki.org/mailman/listinfo/devs
 >> > > >
 >> > > _______________________________________________
 >> > > devs mailing list
 >> > > devs(a)xwiki.org
 >> > > http://lists.xwiki.org/mailman/listinfo/devs
 >> > >
 >> > _______________________________________________
 >> > devs mailing list
 >> > devs(a)xwiki.org
 >> > http://lists.xwiki.org/mailman/listinfo/devs
 > >  >>
 >>
 >>
 >> --
 >> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
 >> Research & Development Engineer at XWiki SAS
 >> Committer on the XWiki.org project
 >> _______________________________________________
 >> devs mailing list
 >> devs(a)xwiki.org
 >> http://lists.xwiki.org/mailman/listinfo/devs
 >>
 > _______________________________________________
 > devs mailing list
 > devs(a)xwiki.org
 > http://lists.xwiki.org/mailman/listinfo/devs
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs

 --
 Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
 Research & Development Engineer at XWiki SAS
 Committer on the XWiki.org project
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs 

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Re: [xwiki-devs] Home Page - Use cases, proposals, what we have until now and what we want to achieve