Hi,
2014-10-28 21:08 GMT+01:00 vincent(a)massol.net <vincent(a)massol.net>et>:
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
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> 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