7:22 a.m.
Hey, guys
I'm an outsider, since I use GateIn/eXo a lot, I subscribed to this list.
Some time ago I wrote to both Benjamin about some suggestions regarding the
products I was using.
I'm forwarding the document we exchanged with comments by exo and me. I
believe the suggestions concerning the Portal is pretty much valid still.
Could you give me a feedback for further discussions?
BTW, nice work. GateIn is looking amazing.
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
8:16 a.m.
Thank you Rafael !
First we should keep portal and WCM discussions seperated, GateIn is
about the portal so I leave the WCM part apart.
Overall
*
Change messages from the default popup (error/warning/info). It
seems messy since there's already JavaScript's alerts and is not
ergonomic. JSF-like messages are much better (they appear in a
box above the form). The user only wants to correct his fields,
the don't want to click any annoying popup.
o
eXo: request forwarded to Portal Team
Agreed, do you know if a Jira was opened ? I don't think there is one on
GTNPORTAL, we should keep this requirement for furture evolution of
WebUI so feel free to add a Jira.
*
There's already a Groovy cache, to save compilation AFAIK. There
could be also a HTML cache, that would cache the whole page, not
a per portlet thing.
There are already multiple layers of cache, what would be interesting
would be to return the correct Last-Modified on HTTP Response but it's
tricky to get. How do you see your HTML cache working with invalidation ?
Language
*
The Language Settings should use the locales-config.xml
definitions (output-encoding and input-encoding) to encode
request parameters. There are a lot of encoding problems through
eXo (try to login with a fake username with accents, for instance)
o
eXo: request forwarded to Portal Team
If there are encoding issues, please report them.
Portlets and HTML rendering
*
Don't render the div tags like VIEW-PAGEBODY, META-DATA-BLOCK,
PORTLET-FRAGMENT, etc (or render the minimum required) with
"display: none". That pollutes the code, makes the downloading
slower, loads the browser and confuses us with eXo's CSS. Rather
these tags should not be shown by default but only in Edit Site,
Edit Mode, etc. If that was done this way because of AJAX, it's
much preferable for the web-designer to have a refresh than a
end-user to have a bloated HTML.
o
eXo: Such a thing will be discussed internally in the new
GateIn project as I would like in WCM a "production" site
without this code.
Not sure if they are required, looks like semantic info
*
A decorator container. Something like a wrapper that would have
a before and an after field that would surround it's contents.
o
eXo: don't understand that point.
o
Rliu: Just like there are column, rows, tab and mixed
container, it would be useful to have a "decorator
container". A container that would decorate it's content.
Imagine (I had to do that) that I wan a PageBody with
rounded corners. There are a lot of methods to do rounded
corners in HTML/CSS, but only a few are applicable because
there's no way to surround PageBody's content (a simple
case: imagine I want a <div> tag before and a </div> after
page content. Or a <center> or <table>, etc)
A wrapper around a page ? around a content of a layout ? Not sure I
understand neither :-/
*
Editing class/style tag of portlet's div is really useful (used
a lot of times in this project I'm in). There should be a field
for each of these (and maybe width/height would be unnecessary)
in Portlet Settings tab.
o
eXo: that's also part of WCM requirements for
accessibility : I'd like to add a class property for each
portlet instance and we have to remove the portlet id
property for w3c compliance. We're on the same wave ?
This is the dreaded issue of the admin portal, the problem is to draw
the line between administrators and developers. Some people will want
limited but easy to understand UI and others will want advanced UI, that
leads to your introduction and you are 100% right.
*
Portlet's id should be editable. Then I could use it as CSS
selector and have meaningful id's in my HTML.
o
eXo: agreed, see previous answer.
True.
*
Navigation, Breadcrumb and Site Map should be done with
server-side scripting.
o
This is much less error-prone (another JavaScript error
wouldn't break my script)
o
We could use caching
o
We could use IDE goodies
o
And I think it's prettier, much more maintainable and the
concept of versioning gets more reasonable.
This is already the case in portal AFAIK.
Thomas.
On 01/04/2010 02:22 PM, rafael liu wrote:
Hey, guys
I'm an outsider, since I use GateIn/eXo a lot, I subscribed to this
list. Some time ago I wrote to both Benjamin about some suggestions
regarding the products I was using.
I'm forwarding the document we exchanged with comments by exo and me.
I believe the suggestions concerning the Portal is pretty much valid
still.
Could you give me a feedback for further discussions?
BTW, nice work. GateIn is looking amazing.
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
4:43 p.m.
Thanks for the time taken to read it Thomas.
I actually didn't opened JIRAs because my features requests were being
refused because they weren't user friendly. That document actually was to
discuss this philosophy..
I do think keeping it user friendly is the way to go, but what good does it
do if we can't address user's needs? I've been doing some PoCs and
presentations with GateIn/eXo and our main competitors here (Liferay, Lumis
and sometimes IBM) have features I always get asked about, and I have to say
"we don't have it, but it can be done".. and it's not only Content
Management features.
On Mon, Jan 11, 2010 at 12:16 PM, Thomas Heute <theute(a)redhat.com> wrote:
Thank you Rafael !
First we should keep portal and WCM discussions seperated, GateIn is about
the portal so I leave the WCM part apart.
Overall
-
Change messages from the default popup (error/warning/info). It seems
messy since there's already JavaScript's alerts and is not ergonomic.
JSF-like messages are much better (they appear in a box above the form). The
user only wants to correct his fields, the don't want to click any annoying
popup.
-
eXo: request forwarded to Portal Team
Agreed, do you know if a Jira was opened ? I don't think there is one on
GTNPORTAL, we should keep this requirement for furture evolution of WebUI so
feel free to add a Jira.
Just opened it: https://jira.jboss.org/jira/browse/GTNPORTAL-475
-
There's already a Groovy cache, to save compilation AFAIK. There could
be also a HTML cache, that would cache the whole page, not a per portlet
thing.
There are already multiple layers of cache, what would be interesting
would be to return the correct Last-Modified on HTTP Response but it's
tricky to get. How do you see your HTML cache working with invalidation ?
Sorry, I was thinking about eXo WCM when I wrote it.
Language
-
The Language Settings should use the locales-config.xml definitions
(output-encoding and input-encoding) to encode request parameters. There are
a lot of encoding problems through eXo (try to login with a fake username
with accents, for instance)
-
eXo: request forwarded to Portal Team
If there are encoding issues, please report them.
Encoding problems I faced in previous version seem to be fixed.
Portlets and HTML rendering
-
Don't render the div tags like VIEW-PAGEBODY, META-DATA-BLOCK,
PORTLET-FRAGMENT, etc (or render the minimum required) with “display: none”.
That pollutes the code, makes the downloading slower, loads the browser and
confuses us with eXo's CSS. Rather these tags should not be shown by default
but only in Edit Site, Edit Mode, etc. If that was done this way because of
AJAX, it's much preferable for the web-designer to have a refresh than a
end-user to have a bloated HTML.
-
eXo: Such a thing will be discussed internally in the new GateIn
project as I would like in WCM a “production” site without this code.
Not sure if they are required, looks like semantic info
Precisely: they has nothing to do with user's portal. That's why I think it
"pollutes the code, makes the downloading slower, loads the browser and
confuses us with eXo's CSS"
-
A decorator container. Something like a wrapper that would have a
before and an after field that would surround it's contents.
-
eXo: don’t understand that point.
-
Rliu: Just like there are column, rows, tab and mixed container, it
would be useful to have a “decorator container”. A container that would
decorate it's content. Imagine (I had to do that) that I wan a PageBody with
rounded corners. There are a lot of methods to do rounded corners in
HTML/CSS, but only a few are applicable because there's no way to surround
PageBody's content (a simple case: imagine I want a <div> tag before and
a
</div> after page content. Or a <center> or <table>, etc)
A wrapper around a page ? around a content of a layout ? Not sure I
understand neither :-/
It would be just a new kind of container (besides columns, rows, mixed and
tabbed). It could contain a portlet, the Page Content or even another
container.
-
Editing class/style tag of portlet's div is really useful (used a lot
of times in this project I'm in). There should be a field for each of these
(and maybe width/height would be unnecessary) in Portlet Settings tab.
-
eXo: that’s also part of WCM requirements for accessibility : I’d
like to add a class property for each portlet instance and we have to remove
the portlet id property for w3c compliance. We’re on the same wave
This is the dreaded issue of the admin portal, the problem is to draw the
line between administrators and developers. Some people will want limited
but easy to understand UI and others will want advanced UI, that leads to
your introduction and you are 100% right.
Actually I was discussing this with people from eXo portal. And I do think
GateIn should keep user friendly, but there are way to conceal it with
advanced features like the ones I wrote in the beginning: eclipse-like
perspectives (like basic and advanced), role based perspectives (like a
developer role) or simply an “advanced” button. "Keeping it simple"
shouldn't be the reason for not implementing a feature..
-
Portlet's id should be editable. Then I could use it as CSS selector
and have meaningful id's in my HTML.
-
eXo: agreed, see previous answer.
True.
Opened a jira: https://jira.jboss.org/jira/browse/GTNPORTAL-476
-
Navigation, Breadcrumb and Site Map should be done with server-side
scripting.
-
This is much less error-prone (another JavaScript error wouldn't
break my script)
-
We could use caching
-
We could use IDE goodies
-
And I think it's prettier, much more maintainable and the concept of
versioning gets more reasonable.
This is already the case in portal AFAIK.
Yeah, just checked it. That wasn't the case in previous eXo portal versions
=) Nice
Thomas.
On 01/04/2010 02:22 PM, rafael liu wrote:
Hey, guys
I'm an outsider, since I use GateIn/eXo a lot, I subscribed to this list.
Some time ago I wrote to both Benjamin about some suggestions regarding the
products I was using.
I'm forwarding the document we exchanged with comments by exo and me. I
believe the suggestions concerning the Portal is pretty much valid still.
Could you give me a feedback for further discussions?
BTW, nice work. GateIn is looking amazing.
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/gatein-dev
--
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net
6069
days inactive
6076
days old
2 comments
2 participants
participants (2)
-
rafael liu -
Thomas Heute