Hi, migration is always big problem. If you make major (LTS )releases too
often clients complain about additional costs and all this hassle. When CMS
releases are rare, it apperars that system is out-dated compare to
competitors ( Wordpress, Drupal). It is really "chicken-egg" problem. I
think that is good that Joomla 3 is already there and is not recommended
for production. It gives time for developers to catch up with modules,
extentions and client ( customer,whoever ) will have fully working CMS. At
least we have some date about support, unlike drupal. There we have another
problems with questions how long drupal6 is going to be supported?
Traditionally Drupal supports the current version, and the previous
> version. When a new version comes out the oldest supported version is
> retired. This is great, except the unpredictable life cycle means that
> clients investing in Drupal sites cannot be certain of the amount of time
> before their site will have to be upgraded,
and the link http://drupal.org/node/1036542 to forum.
Joomla is somewhere between Wordpress and Drupal. More efford should be put
towards marketing strategy to get more "customers in ", build their
awarness etc, then develpers won't be forced to migrate. I do
subcontracting for Drupal and small Jommla projects, recently I lost two
clients because of wordpress ( couldn't convert them to Joomla )...and
started learning " the best CMS on the Planet" it is basically painful
experience. Can somebody tell me what WP gives me what Joomla doesn't (
except security issues ).
Have a nice day.
Tom
On Tue, Nov 13, 2012 at 3:13 PM, TownWebsites <townwebsi...@gmail.com>wrote:
> Version - the migration from V1.5 to 1.6+. I have not tried to do a
> migration from 2.x to 3.x yet so cannot comment, but it had better be
> easier.
> Re: Drupal, it serves a smaller and more professional base. Joomla, like
> it or not, is in a higher volume / lower maintenance capabilities space.
> Drupal does have a much longer LTS support cycle, so for example, I can
> comfortably tell a client that has a Drupal 6 site it is not strictly
> necessary to plan to replace it yet where J1.5x sites I can't tell them the
> same thing. Perhaps that is based on my being closer to J1.5 and it is not
> really any safer to maintain a Drupal 6 site.
> J2.5 end of life in early 2014 is a joke. V3 isn't even recommended yet,
> how can the current version, which has few sites more than one year old and
> which is still recommended for new work, be considered end of life a year
> from now? That is a toy, not a viable development platform. I can't
> tell you how the organization can shift from a two year LTS to something
> more viable, like 4 years minimum. How do the open source OS providers do
> that? Perhaps an answer is that LTS versions have to maintain all
> interfaces which were supported in the prior release so you can double the
> support life of the interfaces, assuring version migrations and extension
> compatability for a longer window. Another answer might be that migration
> tools have to be both easy to use an powerful. Maybe a revenue source has
> to be built to pay a group of LTS support engineers to keep the platform
> relevant; the volunteers can do the choice work, but there needs to be a
> strong steering committee to keep that next generation platform true to a
> mission and a history.
> Bottom line is that Open Source can't mean amateur or you'll lose the
> trust of both the masses and of the developers that make choices to depend
> on the platform. If Wordpress executes better, there won't be much reason
> (or many survivors) to build future version J sites.
> Cheers,
> Charlie
> On Friday, November 9, 2012 4:54:42 PM UTC-5, Andrew Eddie wrote:
>> On 10 November 2012 01:48, TownWebsites <townwe...@gmail.com> wrote:
>>> Constructive criticism:
>> Appreciated, but some specifics are lacking.
>>> The lack of foresight of the need for a migration path between versions
>>> was a fiasco.
>> It would be helpful to know what versions you are talking about.
>>> The duration of LTS versions is far too short to be considered as
>>> serious platform;
>> How would you change the release strategy and, coupled with that, how
>> would you motivate volunteers to be bothered to support a version for an
>> increased length of time?
>>> Thanks for listening; setting up a more active funding / sponsorship and
>>> longer term thinking steering group is fine with me. I'll have to consider
>>> going upstream or down (Drupal or Wordpress) with another difficult
>>> migration and too-short LTS. Bonus points: real documentation, too much
>>> room for error when copying and pasting from other people's work (even
>>> core) to duplicate a functionality and using reading of code as the
>>> documentation.
>> I doubt you'll find the grass is greener on either of those hills. I can
>> tell you now, 1.5 -> 1.6 is a walk in the park compared to keeping up to
>> date with Drupal :)
>> Regards,
>> Andrew Eddie
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-general/-/8i52ESAvpRoJ.
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
> Version - the migration from V1.5 to 1.6+. I have not tried to do a
> migration from 2.x to 3.x yet so cannot comment, but it had better be
> easier.
> Re: Drupal, it serves a smaller and more professional base. Joomla, like
> it or not, is in a higher volume / lower maintenance capabilities space.
> Drupal does have a much longer LTS support cycle, so for example, I can
> comfortably tell a client that has a Drupal 6 site it is not strictly
> necessary to plan to replace it yet where J1.5x sites I can't tell them
> the
> same thing. Perhaps that is based on my being closer to J1.5 and it is
> not
> really any safer to maintain a Drupal 6 site.
> J2.5 end of life in early 2014 is a joke. V3 isn't even recommended yet,
> how can the current version, which has few sites more than one year old
> and
> which is still recommended for new work, be considered end of life a year
> from now? That is a toy, not a viable development platform. I can't
> tell you how the organization can shift from a two year LTS to something
> more viable, like 4 years minimum. How do the open source OS providers do
> that? Perhaps an answer is that LTS versions have to maintain all
> interfaces which were supported in the prior release so you can double the
> support life of the interfaces, assuring version migrations and extension
> compatability for a longer window. Another answer might be that migration
> tools have to be both easy to use an powerful. Maybe a revenue source has
> to be built to pay a group of LTS support engineers to keep the platform
> relevant; the volunteers can do the choice work, but there needs to be a
> strong steering committee to keep that next generation platform true to a
> mission and a history.
> Bottom line is that Open Source can't mean amateur or you'll lose the
> trust
> of both the masses and of the developers that make choices to depend on
> the
> platform. If Wordpress executes better, there won't be much reason (or
> many survivors) to build future version J sites.
> Cheers,
> Charlie
> On Friday, November 9, 2012 4:54:42 PM UTC-5, Andrew Eddie wrote:
>> On 10 November 2012 01:48, TownWebsites <townwe...@gmail.com
>> <javascript:>
>> > wrote:
>>> Constructive criticism:
>> Appreciated, but some specifics are lacking.
>>> The lack of foresight of the need for a migration path between versions
>>> was a fiasco.
>> It would be helpful to know what versions you are talking about.
>>> The duration of LTS versions is far too short to be considered as
>>> serious
>>> platform;
>> How would you change the release strategy and, coupled with that, how
>> would you motivate volunteers to be bothered to support a version for an
>> increased length of time?
>>> Thanks for listening; setting up a more active funding / sponsorship
>>> and
>>> longer term thinking steering group is fine with me. I'll have to
>>> consider
>>> going upstream or down (Drupal or Wordpress) with another difficult
>>> migration and too-short LTS. Bonus points: real documentation, too
>>> much
>>> room for error when copying and pasting from other people's work (even
>>> core) to duplicate a functionality and using reading of code as the
>>> documentation.
>> I doubt you'll find the grass is greener on either of those hills. I can
>> tell you now, 1.5 -> 1.6 is a walk in the park compared to keeping up to
>> date with Drupal :)
>> Regards,
>> Andrew Eddie
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-general/-/8i52ESAvpRoJ.
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
> Hi, migration is always big problem. If you make major (LTS )releases too
> often clients complain about additional costs and all this hassle. When
> CMS
> releases are rare, it apperars that system is out-dated compare to
> competitors ( Wordpress, Drupal). It is really "chicken-egg" problem. I
> think that is good that Joomla 3 is already there and is not recommended
> for production. It gives time for developers to catch up with modules,
> extentions and client ( customer,whoever ) will have fully working CMS. At
> least we have some date about support, unlike drupal. There we have
> another
> problems with questions how long drupal6 is going to be supported?
> Traditionally Drupal supports the current version, and the previous
>> version. When a new version comes out the oldest supported version is
>> retired. This is great, except the unpredictable life cycle means that
>> clients investing in Drupal sites cannot be certain of the amount of
>> time
>> before their site will have to be upgraded,
> and the link http://drupal.org/node/1036542 to forum.
> Joomla is somewhere between Wordpress and Drupal. More efford should be
> put
> towards marketing strategy to get more "customers in ", build their
> awarness etc, then develpers won't be forced to migrate. I do
> subcontracting for Drupal and small Jommla projects, recently I lost two
> clients because of wordpress ( couldn't convert them to Joomla )...and
> started learning " the best CMS on the Planet" it is basically painful
> experience. Can somebody tell me what WP gives me what Joomla doesn't (
> except security issues ).
> Have a nice day.
> Tom
> On Tue, Nov 13, 2012 at 3:13 PM, TownWebsites
> <townwebsi...@gmail.com>wrote:
>> Version - the migration from V1.5 to 1.6+. I have not tried to do a
>> migration from 2.x to 3.x yet so cannot comment, but it had better be
>> easier.
>> Re: Drupal, it serves a smaller and more professional base. Joomla,
>> like
>> it or not, is in a higher volume / lower maintenance capabilities space.
>> Drupal does have a much longer LTS support cycle, so for example, I can
>> comfortably tell a client that has a Drupal 6 site it is not strictly
>> necessary to plan to replace it yet where J1.5x sites I can't tell them
>> the
>> same thing. Perhaps that is based on my being closer to J1.5 and it is
>> not
>> really any safer to maintain a Drupal 6 site.
>> J2.5 end of life in early 2014 is a joke. V3 isn't even recommended
>> yet,
>> how can the current version, which has few sites more than one year old
>> and
>> which is still recommended for new work, be considered end of life a
>> year
>> from now? That is a toy, not a viable development platform. I can't
>> tell you how the organization can shift from a two year LTS to something
>> more viable, like 4 years minimum. How do the open source OS providers
>> do
>> that? Perhaps an answer is that LTS versions have to maintain all
>> interfaces which were supported in the prior release so you can double
>> the
>> support life of the interfaces, assuring version migrations and
>> extension
>> compatability for a longer window. Another answer might be that
>> migration
>> tools have to be both easy to use an powerful. Maybe a revenue source
>> has
>> to be built to pay a group of LTS support engineers to keep the platform
>> relevant; the volunteers can do the choice work, but there needs to be a
>> strong steering committee to keep that next generation platform true to
>> a
>> mission and a history.
>> Bottom line is that Open Source can't mean amateur or you'll lose the
>> trust of both the masses and of the developers that make choices to
>> depend
>> on the platform. If Wordpress executes better, there won't be much
>> reason
>> (or many survivors) to build future version J sites.
>> Cheers,
>> Charlie
>> On Friday, November 9, 2012 4:54:42 PM UTC-5, Andrew Eddie wrote:
>>> On 10 November 2012 01:48, TownWebsites <townwe...@gmail.com> wrote:
>>>> Constructive criticism:
>>> Appreciated, but some specifics are lacking.
>>>> The lack of foresight of the need for a migration path between
>>>> versions
>>>> was a fiasco.
>>> It would be helpful to know what versions you are talking about.
>>>> The duration of LTS versions is far too short to be considered as
>>>> serious platform;
>>> How would you change the release strategy and, coupled with that, how
>>> would you motivate volunteers to be bothered to support a version for
>>> an
>>> increased length of time?
>>>> Thanks for listening; setting up a more active funding / sponsorship
>>>> and
>>>> longer term thinking steering group is fine with me. I'll have to
>>>> consider
>>>> going upstream or down (Drupal or Wordpress) with another difficult
>>>> migration and too-short LTS. Bonus points: real documentation, too
>>>> much
>>>> room for error when copying and pasting from other people's work (even
>>>> core) to duplicate a functionality and using reading of code as the
>>>> documentation.
>>> I doubt you'll find the grass is greener on either of those hills. I
>>> can
>>> tell you now, 1.5 -> 1.6 is a walk in the park compared to keeping up
>>> to
>>> date with Drupal :)
>>> Regards,
>>> Andrew Eddie
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Joomla! General Development" group.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msg/joomla-dev-general/-/8i52ESAvpRoJ.
>> To post to this group, send an email to
>> joomla-dev-general@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomla-dev-general+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
On 13 November 2012 23:27, Marius van Rijnsoever <mariu...@gmail.com> wrote:
This ground has already been covered, but maybe it takes saying something
thrice for it to sink in.
You asked for my suggestions on the development strategy:
> 1. Stop renaming objects/methods/classes just for the sake of it.
No objects/methods/classes are renamed for the sake of it but as you
haven't given any details to support your claim I can't respond to it
directly. What I think you mean to say is that you disagree with the
reasons behind such changes. I recommend you subscribe to the Platform
mailing list and discuss the details there, and also plug the
developer.joomla.org news feed into your feed reader with the maximum alert
you can give it. Discuss changes as they are happening.
> 2. Use the appropriate protocols for depreciating and don't remove
> code within 6 months of creating a docblock on github
There are appropriate protocols in place but as you haven't given any
details to support your claim I can't respond to it directly. Once you
have subscribed to the Platform mailing list, please support this point #2
with the details and we'll have a look at what the problem is. That would
be the appropriate response protocol for you in this case.
> 3. Extend the LTS support to give business' the confidence that their
> site will remain secure for more than 1 year (as EOL is early 2014 for
> joomla 2.5). If you don't want to support bug releases, then call it
> "security only releases".
I don't see any issue at all with that other than who needing more people
to do a tour of duty on the JSST (because they will have three versions of
Joomla to worry about instead of two are any point in time). Do you have
any concept of the work load the JSST is already under and what are you
willing to do to promote participation in the JSST to deal with the higher
workload?
I was still thinking about this idea of having different Admin Interfaces for the different skills of users, such as Google Adsense does. (Ergonomy is different for experts and novices).
*I just realize that the actual Joomla! ACL permit something near that. I think it would be quite easy to change it a little bit to give the possibility to create Ergnomy Groups.*
An ergonomy group would be defined by the Super User (people like Terry Arthur) and would give him the possibility to easilyconfigure a custom admin interface, with a selection of functionalities (for his clients).
Sorry to insist so much on that idea, but my wife is actually doing a PhD in cognitive science on the subject of ergonomy in Human Computer Interaction, and the idea that an 'ergonomic interface' is different for experts and novices is a very important concept in that discipline. It is the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
With your wife's experience, maybe we could start a topic on 'Joomla! Admin
Ergonomics' (if one does not exist) and put down some guidelines.
I would be happy to experiment with this as I am currently trying to design
a course for beginners to Joomla! - Getting started designing web sites in
1hr with Joomla!
We'll have pre-installed instances, and the flatter we can make the
learning curve for new entrants the better.
Feel free to follow up with me on this - seems really interesting.
There is a dichotomy between feature rich interface for advanced users and
needs, and beginners who tend to get overwhelmed and confused.
What you propose appears to be a very intelligent, and rather simple
(famous last words) approach, and if we can get the project team some
guidelines, then we'll take the workload of them and contribute in a really
positive way.
I feel it would certainly entrants to Joomla! which is where my major focus
is right now - so it dovetails quite nicely!
On Tue, Nov 13, 2012 at 9:49 PM, Zop Zoup <zopz...@gmail.com> wrote:
> Hi there,
> I was still thinking about this idea of having different Admin Interfaces
> for the different skills of users, such as Google Adsense does. (Ergonomy
> is different for experts and novices).
> *I just realize that the actual Joomla! ACL permit something near that. I
> think it would be quite easy to change it a little bit to give the
> possibility to create Ergnomy Groups.*
> An ergonomy group would be defined by the Super User (people like Terry
> Arthur) and would give him the possibility to easilyconfigure a custom
> admin interface, with a selection of functionalities (for his clients).
> Sorry to insist so much on that idea, but my wife is actually doing a PhD
> in cognitive science on the subject of ergonomy in Human Computer
> Interaction, and the idea that an 'ergonomic interface' is different for
> experts and novices is a very important concept in that discipline. It is
> the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Didnt someone state exactly this many many posts earlier.
You dont need to "hack the acl" you should be able to achieve everything you want out of the box. Having said that there is no doubt that its a time consuming and complex task. What I would suggest is to make a start, document it and then share your progress so that others can contribute. Once created it will be a trivial task to add this set of acl rules (simplified, reduced functionality interface) to the core installation as its just a database entry
On Wednesday, 14 November 2012 03:38:48 UTC, Niv Froehlich wrote:
> Beautiful idea - usability is key.
> With your wife's experience, maybe we could start a topic on 'Joomla! > Admin Ergonomics' (if one does not exist) and put down some guidelines.
> I would be happy to experiment with this as I am currently trying to > design a course for beginners to Joomla! - Getting started designing web > sites in 1hr with Joomla!
> We'll have pre-installed instances, and the flatter we can make the > learning curve for new entrants the better.
> Feel free to follow up with me on this - seems really interesting.
> There is a dichotomy between feature rich interface for advanced users and > needs, and beginners who tend to get overwhelmed and confused.
> What you propose appears to be a very intelligent, and rather simple > (famous last words) approach, and if we can get the project team some > guidelines, then we'll take the workload of them and contribute in a really > positive way.
> I feel it would certainly entrants to Joomla! which is where my major > focus is right now - so it dovetails quite nicely!
> Niv
> On Tue, Nov 13, 2012 at 9:49 PM, Zop Zoup <zop...@gmail.com <javascript:>>wrote:
>> Hi there,
>> I was still thinking about this idea of having different Admin Interfaces >> for the different skills of users, such as Google Adsense does. (Ergonomy >> is different for experts and novices).
>> *I just realize that the actual Joomla! ACL permit something near that. >> I think it would be quite easy to change it a little bit to give the >> possibility to create Ergnomy Groups.*
>> An ergonomy group would be defined by the Super User (people like Terry >> Arthur) and would give him the possibility to easilyconfigure a custom >> admin interface, with a selection of functionalities (for his clients).
>> Sorry to insist so much on that idea, but my wife is actually doing a PhD >> in cognitive science on the subject of ergonomy in Human Computer >> Interaction, and the idea that an 'ergonomic interface' is different for >> experts and novices is a very important concept in that discipline. It is >> the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
>> To post to this group, send an email to joomla-de...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> joomla-dev-general+unsubscribe@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
You are right, there is already such functionality:
- 'Super Users' group users have access to whole administrator
functionality
- 'Administrator' users have some components disabled (see Permissions
-> Access Administration Interface in component options)
- 'Manager' users see very little (Own profile, Articles if I recall
correctly)
So it's there, but it's not known/ used:
Once a newbie installs Joomla, logs into a administration area as a
super user (created automatically on install) and becomes overwhelmed
by functionality.
While this is fine for experienced users, IMHO we should think about
how give an option to give users what they expect:
In install wizard there's an option in Joomla 3.0 to use different
sample data (Blog/ Brochure/ Learn Joomla/ Test). Let's connect it
with different interface flavors (create non- Super user with modified
interface/ some components disabled).
This looks like simple thing that would help much.
BTW:
I have a feeling that this discussion slipped too much into one topic
(backward compatibility + LTS duration).
On Nov 14, 3:49 am, Zop Zoup <zopz...@gmail.com> wrote:
> I was still thinking about this idea of having different Admin Interfaces
> for the different skills of users, such as Google Adsense does. (Ergonomy
> is different for experts and novices).
> *I just realize that the actual Joomla! ACL permit something near that. I
> think it would be quite easy to change it a little bit to give the
> possibility to create Ergnomy Groups.*
> An ergonomy group would be defined by the Super User (people like Terry
> Arthur) and would give him the possibility to easilyconfigure a custom
> admin interface, with a selection of functionalities (for his clients).
> Sorry to insist so much on that idea, but my wife is actually doing a PhD
> in cognitive science on the subject of ergonomy in Human Computer
> Interaction, and the idea that an 'ergonomic interface' is different for
> experts and novices is a very important concept in that discipline. It is
> the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
Maybe all that is needed is the functionality to ask a "Super User" if they want to view the backend as a "Super User" or as some lower level group (Administrator, Manager).
> You are right, there is already such functionality:
> - 'Super Users' group users have access to whole administrator
> functionality
> - 'Administrator' users have some components disabled (see Permissions
> -> Access Administration Interface in component options)
> - 'Manager' users see very little (Own profile, Articles if I recall
> correctly)
> So it's there, but it's not known/ used:
> Once a newbie installs Joomla, logs into a administration area as a
> super user (created automatically on install) and becomes overwhelmed
> by functionality.
> While this is fine for experienced users, IMHO we should think about
> how give an option to give users what they expect:
> In install wizard there's an option in Joomla 3.0 to use different
> sample data (Blog/ Brochure/ Learn Joomla/ Test). Let's connect it
> with different interface flavors (create non- Super user with modified
> interface/ some components disabled).
> This looks like simple thing that would help much.
> BTW:
> I have a feeling that this discussion slipped too much into one topic
> (backward compatibility + LTS duration).
> On Nov 14, 3:49 am, Zop Zoup <zopz...@gmail.com> wrote:
>> Hi there,
>> I was still thinking about this idea of having different Admin Interfaces
>> for the different skills of users, such as Google Adsense does. (Ergonomy
>> is different for experts and novices).
>> *I just realize that the actual Joomla! ACL permit something near that. I
>> think it would be quite easy to change it a little bit to give the
>> possibility to create Ergnomy Groups.*
>> An ergonomy group would be defined by the Super User (people like Terry
>> Arthur) and would give him the possibility to easilyconfigure a custom
>> admin interface, with a selection of functionalities (for his clients).
>> Sorry to insist so much on that idea, but my wife is actually doing a PhD
>> in cognitive science on the subject of ergonomy in Human Computer
>> Interaction, and the idea that an 'ergonomic interface' is different for
>> experts and novices is a very important concept in that discipline. It is
>> the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
Plus Administrator/ Manager components visibility would be preset
depending on chosen sample data.
IMHO no need to enable Contacts, Messaging, Newsfeeds, Redirect,
Search, Plugins, Language, ACL, User notes and so on for all sample
datasets (and first encounter with Joomla backend).
piotr
On Nov 14, 8:14 pm, Brad Gies <rbg...@gmail.com> wrote:
> Maybe all that is needed is the functionality to ask a "Super User" if
> they want to view the backend as a "Super User" or as some lower level
> group (Administrator, Manager).
> Brad.
> On 2012-11-14 6:05 PM, piotr_cz wrote:
> > Hey Zop Zoup.
> > You are right, there is already such functionality:
> > - 'Super Users' group users have access to whole administrator
> > functionality
> > - 'Administrator' users have some components disabled (see Permissions
> > -> Access Administration Interface in component options)
> > - 'Manager' users see very little (Own profile, Articles if I recall
> > correctly)
> > So it's there, but it's not known/ used:
> > Once a newbie installs Joomla, logs into a administration area as a
> > super user (created automatically on install) and becomes overwhelmed
> > by functionality.
> > While this is fine for experienced users, IMHO we should think about
> > how give an option to give users what they expect:
> > In install wizard there's an option in Joomla 3.0 to use different
> > sample data (Blog/ Brochure/ Learn Joomla/ Test). Let's connect it
> > with different interface flavors (create non- Super user with modified
> > interface/ some components disabled).
> > This looks like simple thing that would help much.
> > BTW:
> > I have a feeling that this discussion slipped too much into one topic
> > (backward compatibility + LTS duration).
> > On Nov 14, 3:49 am, Zop Zoup <zopz...@gmail.com> wrote:
> >> Hi there,
> >> I was still thinking about this idea of having different Admin Interfaces
> >> for the different skills of users, such as Google Adsense does. (Ergonomy
> >> is different for experts and novices).
> >> *I just realize that the actual Joomla! ACL permit something near that. I
> >> think it would be quite easy to change it a little bit to give the
> >> possibility to create Ergnomy Groups.*
> >> An ergonomy group would be defined by the Super User (people like Terry
> >> Arthur) and would give him the possibility to easilyconfigure a custom
> >> admin interface, with a selection of functionalities (for his clients).
> >> Sorry to insist so much on that idea, but my wife is actually doing a PhD
> >> in cognitive science on the subject of ergonomy in Human Computer
> >> Interaction, and the idea that an 'ergonomic interface' is different for
> >> experts and novices is a very important concept in that discipline. It is
> >> the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
Of what you listed, the only thing you can't hide is User Notes, because
it is a part of the com_users component and not separate. Everything else
you can hide with ACL, including the ACL.
The sample data's intended to demonstrate the features of Joomla. I'd
advise against setting up a live site with a sample data install since it
will dump a lot of stuff into your managers that you don't want or
particularly need depending on the project. To me, the sample data is
intended for development environments where folks are learning about
Joomla or playing with the code to see what they can (and possibly cannot)
do. Personally, I think it's a bad idea to not have the extensions
enabled with the sample data, which would make some users think its harder
to get to work with com_contact (for example). I do have one idea though
which I'll get to in a moment.
The default structure mimics (mostly) how things were for 1.5 and its ACL
to help ease that transition. Now that we're over that hump, perhaps its
time to revisit those defaults. Remember, there is a default ACL structure
for when the site is installed without sample data, and potentially, every
sample data set could have a different ACL structure. It's even possible
for us to add one, say sample_acl.sql, which could demonstrate what's
being discussed here with using the ACL to hide "advanced" features. So,
it could by default replace the Manager/Administrator groups with "Basic
Admin", "Intermediate Admin", and "Advanced Admin", which would each be
able to see (and obviously do) more. Just a thought.
On 11/14/12 5:01 PM, "piotr_cz" <pkoniec...@hotmail.com> wrote:
>Plus Administrator/ Manager components visibility would be preset
>depending on chosen sample data.
>IMHO no need to enable Contacts, Messaging, Newsfeeds, Redirect,
>Search, Plugins, Language, ACL, User notes and so on for all sample
>datasets (and first encounter with Joomla backend).
>piotr
>On Nov 14, 8:14 pm, Brad Gies <rbg...@gmail.com> wrote:
>> Maybe all that is needed is the functionality to ask a "Super User" if
>> they want to view the backend as a "Super User" or as some lower level
>> group (Administrator, Manager).
>> Brad.
>> On 2012-11-14 6:05 PM, piotr_cz wrote:
>> > Hey Zop Zoup.
>> > You are right, there is already such functionality:
>> > - 'Super Users' group users have access to whole administrator
>> > functionality
>> > - 'Administrator' users have some components disabled (see Permissions
>> > -> Access Administration Interface in component options)
>> > - 'Manager' users see very little (Own profile, Articles if I recall
>> > correctly)
>> > So it's there, but it's not known/ used:
>> > Once a newbie installs Joomla, logs into a administration area as a
>> > super user (created automatically on install) and becomes overwhelmed
>> > by functionality.
>> > While this is fine for experienced users, IMHO we should think about
>> > how give an option to give users what they expect:
>> > In install wizard there's an option in Joomla 3.0 to use different
>> > sample data (Blog/ Brochure/ Learn Joomla/ Test). Let's connect it
>> > with different interface flavors (create non- Super user with modified
>> > interface/ some components disabled).
>> > This looks like simple thing that would help much.
>> > BTW:
>> > I have a feeling that this discussion slipped too much into one topic
>> > (backward compatibility + LTS duration).
>> > On Nov 14, 3:49 am, Zop Zoup <zopz...@gmail.com> wrote:
>> >> Hi there,
>> >> I was still thinking about this idea of having different Admin
>>Interfaces
>> >> for the different skills of users, such as Google Adsense does.
>>(Ergonomy
>> >> is different for experts and novices).
>> >> *I just realize that the actual Joomla! ACL permit something near
>>that. I
>> >> think it would be quite easy to change it a little bit to give the
>> >> possibility to create Ergnomy Groups.*
>> >> An ergonomy group would be defined by the Super User (people like
>>Terry
>> >> Arthur) and would give him the possibility to easilyconfigure a
>>custom
>> >> admin interface, with a selection of functionalities (for his
>>clients).
>> >> Sorry to insist so much on that idea, but my wife is actually doing
>>a PhD
>> >> in cognitive science on the subject of ergonomy in Human Computer
>> >> Interaction, and the idea that an 'ergonomic interface' is different
>>for
>> >> experts and novices is a very important concept in that discipline.
>>It is
>> >> the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
>> >> *So, what about hacking ACL to do of joomla! the first CMS respecting
>> >> Bastien&Scapin's ergonomics recomendations ? *
>-- >You received this message because you are subscribed to the Google Groups
>"Joomla! General Development" group.
>To post to this group, send an email to
>joomla-dev-general@googlegroups.com.
>To unsubscribe from this group, send email to
>joomla-dev-general+unsubscribe@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/joomla-dev-general?hl=en-GB.
On Wed, Nov 14, 2012 at 4:26 AM, Andrew Eddie <mambob...@gmail.com> wrote:
> There are appropriate protocols in place but as you haven't given any
> details to support your claim I can't respond to it directly.
I did provide exact information:
On Tue, Nov 13, 2012 at 9:27 PM, Marius van Rijnsoever
> It seems that a lot of code was depreciated in the platform 12.1
> release (used for joomla 3.0 beta) and then actually removed in
> platform 12.2 (used in Joomla 3.0.0). Therefore even the current
> development strategy is not implemented properly.
JFTP was removed without depreciating (yes I know it is now named
differently, but again any extension that used it broke.
etc,etc,etc.
Do I need to list this for every 100 items listed as "has been
removed" in the Joomla 3.0 backward compatibility document? I do
understand that the platform developers love doing whatever they want
to improve the code. But it is untrue to state that depreciated code
is only removed every 3 years.
Getting back to the user interface topic. Any reason why the full
front-end editor from GCOS was not implemented in the joomla cms. (It
thought it was pretty awesome to be able to edit all texts and move
around modules without even opening the admin interface).
If you're using jimport('joomla.client.ftp') and running Joomla 3.0
near as I can tell it should work. In fact I tested it with the
following code and it handed me back an object:
Are you seriously just looking through the source code just guessing
that things are broken?
Andrew explained earlier someone decided they wanted to deviate from
the established standard for naming methods (I won't comment on if
they did it without thinking or intentionally, it really doesn't
matter). We fixed that. It shouldn't have gotten in and now with
better code reviewing tools it won't get in. Unfortunately we didn't
have that level of quality control in the past but we've got much
better review mechanisms in place to help prevent those accidental API
additions. Someone made a mistake, we fixed it. We apologise in
advance for being human.
The hasUTF thing was introduced in 1.6 near as I can tell which is
January 2011 and was grandfathered into Platform 11.1 (that being the
first release of the platform so everything prior to that was @since
then). It was deprecated in Platform 11.3 and removed with 12.1. So
I'll grant you that there was a small period of time for deprecation
in this case, however if this was insufficient for you then you should
have said something at the time. As noted elsewhere we're improving
documentation and tagging to make it even easier to keep track of
things including building tools to automatically collate changelogs
from pull requests. This said, I'm not sure what the penetration of
usage for "hasUTF" is but beyond projects like your own where you
actively connect to third party databases - I'm not sure how large an
impact this was on the wider developer community versus your own
sandpit.
<mariu...@gmail.com> wrote:
> On Wed, Nov 14, 2012 at 4:26 AM, Andrew Eddie <mambob...@gmail.com> wrote:
>> There are appropriate protocols in place but as you haven't given any
>> details to support your claim I can't respond to it directly.
>> It seems that a lot of code was depreciated in the platform 12.1
>> release (used for joomla 3.0 beta) and then actually removed in
>> platform 12.2 (used in Joomla 3.0.0). Therefore even the current
>> development strategy is not implemented properly.
> JFTP was removed without depreciating (yes I know it is now named
> differently, but again any extension that used it broke.
> etc,etc,etc.
> Do I need to list this for every 100 items listed as "has been
> removed" in the Joomla 3.0 backward compatibility document? I do
> understand that the platform developers love doing whatever they want
> to improve the code. But it is untrue to state that depreciated code
> is only removed every 3 years.
> Getting back to the user interface topic. Any reason why the full
> front-end editor from GCOS was not implemented in the joomla cms. (It
> thought it was pretty awesome to be able to edit all texts and move
> around modules without even opening the admin interface).
> Thanks, Marius
> --
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
> To post to this group, send an email to joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
I know that these things can be hidden. But I don't believe first-time
user will find a way how to do it. This involves understanding User
groups, Permissions, evaluating each component, creating new user. The
time to figure it out s(he) would rather spend on working on the site.
Or choose a different medium.
You are right about the sample data, I suppose it should be other way
around:
- During installation process there are few profiles to choose from:
Blog/ Brochure/ Learn Joomla/ Test / Full functionality (similar with
sample data types).
- Besides 'administrator' there is another user created (Administrator
group) for whom some functionality based on selected profile is
hidden/ revealed
- There is an option to install sample dataset, relevant to selected
profile
- Information what is shown/ hidden and that it's possible to enable
it clicking in Extensions > Manage > red tick next to component.
Creating two users on installation is not something uncommon. When you
install OS (linux/ Windows) there are accounts created for super user
and for everyday work. I've seen it even in my wifi router (by default
there is 'admin' and 'user'), probably all smartphones run in user
mode (for full functionality = super user need to be rooted/
jailbroken).
If the installation is base for a project for client, user might just
hand over the credentials to him and use 'administrator' account (at
this point learned how to use Joomla).
I'm not a professional extensions developer (although I develop
extensions) like many people on this thread. I create websites for
people that they can manage mostly by themselves.
I've heard opinions that Joomla is bloated and learning curve is steep
from clients, people from industry, IT students, and lots on
ux.joomla.org. New UI helped but still I see there are opportunities
for improvement.
Times are changing. Not so long time ago just geeks had computers at
home. Now most people know how use social media to publish content
(tweet, status messages, facebook pages, blog services) and if we make
it harder to use Joomla as a medium, they will simply choose a
different one.
That's how I explain to myself the decline in awareness of Joomla.
There are few efforts to slim down Joomla package, but these are
mostly made by guys like me for their own clients. This doesn't help
Joomla as a brand, as these distributions are perceived by end users
as different tool.
On Nov 15, 12:37 am, Michael Babker <michael.bab...@gmail.com> wrote:
> Of what you listed, the only thing you can't hide is User Notes, because
> it is a part of the com_users component and not separate. Everything else
> you can hide with ACL, including the ACL.
> The sample data's intended to demonstrate the features of Joomla. I'd
> advise against setting up a live site with a sample data install since it
> will dump a lot of stuff into your managers that you don't want or
> particularly need depending on the project. To me, the sample data is
> intended for development environments where folks are learning about
> Joomla or playing with the code to see what they can (and possibly cannot)
> do. Personally, I think it's a bad idea to not have the extensions
> enabled with the sample data, which would make some users think its harder
> to get to work with com_contact (for example). I do have one idea though
> which I'll get to in a moment.
> The default structure mimics (mostly) how things were for 1.5 and its ACL
> to help ease that transition. Now that we're over that hump, perhaps its
> time to revisit those defaults. Remember, there is a default ACL structure
> for when the site is installed without sample data, and potentially, every
> sample data set could have a different ACL structure. It's even possible
> for us to add one, say sample_acl.sql, which could demonstrate what's
> being discussed here with using the ACL to hide "advanced" features. So,
> it could by default replace the Manager/Administrator groups with "Basic
> Admin", "Intermediate Admin", and "Advanced Admin", which would each be
> able to see (and obviously do) more. Just a thought.
> On 11/14/12 5:01 PM, "piotr_cz" <pkoniec...@hotmail.com> wrote:
> >Yes, that's what I mean.
> >Plus Administrator/ Manager components visibility would be preset
> >depending on chosen sample data.
> >IMHO no need to enable Contacts, Messaging, Newsfeeds, Redirect,
> >Search, Plugins, Language, ACL, User notes and so on for all sample
> >datasets (and first encounter with Joomla backend).
> >piotr
> >On Nov 14, 8:14 pm, Brad Gies <rbg...@gmail.com> wrote:
> >> Maybe all that is needed is the functionality to ask a "Super User" if
> >> they want to view the backend as a "Super User" or as some lower level
> >> group (Administrator, Manager).
> >> Brad.
> >> On 2012-11-14 6:05 PM, piotr_cz wrote:
> >> > Hey Zop Zoup.
> >> > You are right, there is already such functionality:
> >> > - 'Super Users' group users have access to whole administrator
> >> > functionality
> >> > - 'Administrator' users have some components disabled (see Permissions
> >> > -> Access Administration Interface in component options)
> >> > - 'Manager' users see very little (Own profile, Articles if I recall
> >> > correctly)
> >> > So it's there, but it's not known/ used:
> >> > Once a newbie installs Joomla, logs into a administration area as a
> >> > super user (created automatically on install) and becomes overwhelmed
> >> > by functionality.
> >> > While this is fine for experienced users, IMHO we should think about
> >> > how give an option to give users what they expect:
> >> > In install wizard there's an option in Joomla 3.0 to use different
> >> > sample data (Blog/ Brochure/ Learn Joomla/ Test). Let's connect it
> >> > with different interface flavors (create non- Super user with modified
> >> > interface/ some components disabled).
> >> > This looks like simple thing that would help much.
> >> > BTW:
> >> > I have a feeling that this discussion slipped too much into one topic
> >> > (backward compatibility + LTS duration).
> >> > On Nov 14, 3:49 am, Zop Zoup <zopz...@gmail.com> wrote:
> >> >> Hi there,
> >> >> I was still thinking about this idea of having different Admin
> >>Interfaces
> >> >> for the different skills of users, such as Google Adsense does.
> >>(Ergonomy
> >> >> is different for experts and novices).
> >> >> *I just realize that the actual Joomla! ACL permit something near
> >>that. I
> >> >> think it would be quite easy to change it a little bit to give the
> >> >> possibility to create Ergnomy Groups.*
> >> >> An ergonomy group would be defined by the Super User (people like
> >>Terry
> >> >> Arthur) and would give him the possibility to easilyconfigure a
> >>custom
> >> >> admin interface, with a selection of functionalities (for his
> >>clients).
> >> >> Sorry to insist so much on that idea, but my wife is actually doing
> >>a PhD
> >> >> in cognitive science on the subject of ergonomy in Human Computer
> >> >> Interaction, and the idea that an 'ergonomic interface' is different
> >>for
> >> >> experts and novices is a very important concept in that discipline.
> >>It is
> >> >> the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
> >> >> *So, what about hacking ACL to do of joomla! the first CMS respecting
> >> >> Bastien&Scapin's ergonomics recomendations ? *
> >--
> >You received this message because you are subscribed to the Google Groups
> >"Joomla! General Development" group.
> >To post to this group, send an email to
> >joomla-dev-general@googlegroups.com.
> >To unsubscribe from this group, send email to
> >joomla-dev-general+unsubscribe@googlegroups.com.
> >For more options, visit this group at
> >http://groups.google.com/group/joomla-dev-general?hl=en-GB.
I don't want to keep arguing about this, but Andrew specifically asked me
for a example and I picked randomly 3 out of a 100 removed API calls on
joomla 3.0.
I do not know the penetrance of these 100 deleted API calls, but neither
does the PLT :)
Just replying as I was asked to backup that backward compatibility is
broken with minimal notice. I agree with other people that nothing will
change or will be achieved by further discussing backward compatibility as
everybody opinions are set on both sides.
On Nov 15, 2012 4:46 PM, "Sam Moffatt" <pasa...@gmail.com> wrote:
> If you're using jimport('joomla.client.ftp') and running Joomla 3.0
> near as I can tell it should work. In fact I tested it with the
> following code and it handed me back an object:
> Are you seriously just looking through the source code just guessing
> that things are broken?
> Andrew explained earlier someone decided they wanted to deviate from
> the established standard for naming methods (I won't comment on if
> they did it without thinking or intentionally, it really doesn't
> matter). We fixed that. It shouldn't have gotten in and now with
> better code reviewing tools it won't get in. Unfortunately we didn't
> have that level of quality control in the past but we've got much
> better review mechanisms in place to help prevent those accidental API
> additions. Someone made a mistake, we fixed it. We apologise in
> advance for being human.
> The hasUTF thing was introduced in 1.6 near as I can tell which is
> January 2011 and was grandfathered into Platform 11.1 (that being the
> first release of the platform so everything prior to that was @since
> then). It was deprecated in Platform 11.3 and removed with 12.1. So
> I'll grant you that there was a small period of time for deprecation
> in this case, however if this was insufficient for you then you should
> have said something at the time. As noted elsewhere we're improving
> documentation and tagging to make it even easier to keep track of
> things including building tools to automatically collate changelogs
> from pull requests. This said, I'm not sure what the penetration of
> usage for "hasUTF" is but beyond projects like your own where you
> actively connect to third party databases - I'm not sure how large an
> impact this was on the wider developer community versus your own
> sandpit.
> On Wed, Nov 14, 2012 at 11:51 PM, Marius van Rijnsoever
> <mariu...@gmail.com> wrote:
> > On Wed, Nov 14, 2012 at 4:26 AM, Andrew Eddie <mambob...@gmail.com>
> wrote:
> >> There are appropriate protocols in place but as you haven't given any
> >> details to support your claim I can't respond to it directly.
> > I did provide exact information:
> > On Tue, Nov 13, 2012 at 9:27 PM, Marius van Rijnsoever
> > <mariu...@gmail.com> wrote:
> >> Search the following document for "has been removed" (94 matches) and
> >> "is now called" (4 matches)
> >> It seems that a lot of code was depreciated in the platform 12.1
> >> release (used for joomla 3.0 beta) and then actually removed in
> >> platform 12.2 (used in Joomla 3.0.0). Therefore even the current
> >> development strategy is not implemented properly.
> > JFTP was removed without depreciating (yes I know it is now named
> > differently, but again any extension that used it broke.
> > etc,etc,etc.
> > Do I need to list this for every 100 items listed as "has been
> > removed" in the Joomla 3.0 backward compatibility document? I do
> > understand that the platform developers love doing whatever they want
> > to improve the code. But it is untrue to state that depreciated code
> > is only removed every 3 years.
> > Getting back to the user interface topic. Any reason why the full
> > front-end editor from GCOS was not implemented in the joomla cms. (It
> > thought it was pretty awesome to be able to edit all texts and move
> > around modules without even opening the admin interface).
> > Thanks, Marius
> > --
> > You received this message because you are subscribed to the Google
> Groups "Joomla! General Development" group.
> > To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> > To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
On Thursday, 15 November 2012, Marius van Rijnsoever wrote:
> Just replying as I was asked to backup that backward compatibility is
> broken
As the development strategy allows for with an increment in major version.
> with minimal notice.
While I'll concede 6 months is too short for the platform from deprecation
to removal, from the cms's point if view it was still around 12 months.
6-12 months advance notice before a major upgrade is plenty of time. But
if you don't read the memo, it doesn't matter if we gave you 10 years
notice.
Nothing more to add to Sam's comments. As for the GSOC code, what's
stopping you from making a pull request?
>Of what you listed, the only thing you can't hide is User Notes, because
>it is a part of the com_users component and not separate. Everything else
>you can hide with ACL, including the ACL.
>The sample data's intended to demonstrate the features of Joomla. I'd
>advise against setting up a live site with a sample data install since it
>will dump a lot of stuff into your managers that you don't want or
>particularly need depending on the project. To me, the sample data is
>intended for development environments where folks are learning about
>Joomla or playing with the code to see what they can (and possibly cannot)
>do. Personally, I think it's a bad idea to not have the extensions
>enabled with the sample data, which would make some users think its harder
>to get to work with com_contact (for example). I do have one idea though
>which I'll get to in a moment.
>The default structure mimics (mostly) how things were for 1.5 and its ACL
>to help ease that transition. Now that we're over that hump, perhaps its
>time to revisit those defaults. Remember, there is a default ACL structure
>for when the site is installed without sample data, and potentially, every
>sample data set could have a different ACL structure. It's even possible
>for us to add one, say sample_acl.sql, which could demonstrate what's
>being discussed here with using the ACL to hide "advanced" features. So,
>it could by default replace the Manager/Administrator groups with "Basic
>Admin", "Intermediate Admin", and "Advanced Admin", which would each be
>able to see (and obviously do) more. Just a thought.
>>Plus Administrator/ Manager components visibility would be preset
>>depending on chosen sample data.
>>IMHO no need to enable Contacts, Messaging, Newsfeeds, Redirect,
>>Search, Plugins, Language, ACL, User notes and so on for all sample
>>datasets (and first encounter with Joomla backend).
>>piotr
>>On Nov 14, 8:14 pm, Brad Gies <rbg...@gmail.com> wrote:
>>> Maybe all that is needed is the functionality to ask a "Super User" if
>>> they want to view the backend as a "Super User" or as some lower level
>>> group (Administrator, Manager).
>>> Brad.
>>> On 2012-11-14 6:05 PM, piotr_cz wrote:
>>> > Hey Zop Zoup.
>>> > You are right, there is already such functionality:
>>> > - 'Super Users' group users have access to whole administrator
>>> > functionality
>>> > - 'Administrator' users have some components disabled (see Permissions
>>> > -> Access Administration Interface in component options)
>>> > - 'Manager' users see very little (Own profile, Articles if I recall
>>> > correctly)
>>> > So it's there, but it's not known/ used:
>>> > Once a newbie installs Joomla, logs into a administration area as a
>>> > super user (created automatically on install) and becomes overwhelmed
>>> > by functionality.
>>> > While this is fine for experienced users, IMHO we should think about
>>> > how give an option to give users what they expect:
>>> > In install wizard there's an option in Joomla 3.0 to use different
>>> > sample data (Blog/ Brochure/ Learn Joomla/ Test). Let's connect it
>>> > with different interface flavors (create non- Super user with modified
>>> > interface/ some components disabled).
>>> > This looks like simple thing that would help much.
>>> > BTW:
>>> > I have a feeling that this discussion slipped too much into one topic
>>> > (backward compatibility + LTS duration).
>>> > On Nov 14, 3:49 am, Zop Zoup <zopz...@gmail.com> wrote:
>>> >> Hi there,
>>> >> I was still thinking about this idea of having different Admin
>>>Interfaces
>>> >> for the different skills of users, such as Google Adsense does.
>>>(Ergonomy
>>> >> is different for experts and novices).
>>> >> *I just realize that the actual Joomla! ACL permit something near
> >>that. I
>>> >> think it would be quite easy to change it a little bit to give the
>>> >> possibility to create Ergnomy Groups.*
>>> >> An ergonomy group would be defined by the Super User (people like
>>>Terry
>>> >> Arthur) and would give him the possibility to easilyconfigure a
>>>custom
>>> >> admin interface, with a selection of functionalities (for his
>>>clients).
>>> >> Sorry to insist so much on that idea, but my wife is actually doing
>>>a PhD
>>> >> in cognitive science on the subject of ergonomy in Human Computer
>>> >> Interaction, and the idea that an 'ergonomic interface' is different
>>>for
>>> >> experts and novices is a very important concept in that discipline.
>>>It is
>>> >> the 4th criteria of Bastien & Scapin, called *ADAPTABILITY.* See :
>>> >> *So, what about hacking ACL to do of joomla! the first CMS respecting
>>> >> Bastien&Scapin's ergonomics recomendations ? *
>>--
>>You received this message because you are subscribed to the Google Groups
>>"Joomla! General Development" group.
>>To post to this group, send an email to
>>joomla-dev-general@googlegroups.com.
>>To unsubscribe from this group, send email to
>>joomla-dev-general+unsubscribe@googlegroups.com.
>>For more options, visit this group at
>>http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>--
>You received this message because you are subscribed to the Google >Groups "Joomla! General Development" group.
>To post to this group, send an email to joomla-dev-general@googlegroups.com.
>To unsubscribe from this group, send email to >joomla-dev-general+unsubscribe@googlegroups.com.
>For more options, visit this group at >http://groups.google.com/group/joomla-dev-general?hl=en-GB.
--
>Please keep the Subject wording in your answers
This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the
intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.
-----------------------------------------------------------
Jean-Marie Simonet / infograf768
Joomla Production Working group
Joomla! Translation Coordination Team
Given some of the topics raised in this thread, it would be prudent for all
concerned to have your voice heard in the "Proposal to add 3.2 release" thread
on the CMS list. Speak now or forever hold your peace.
On Thu, Nov 15, 2012 at 10:55 PM, Andrew Eddie <mambob...@gmail.com> wrote:
> As for the GSOC code, what's stopping you from making a pull request?
There was a working concept for Joomla 1.6 that was planned for
inclusion. It would be great to know why it was not included before I
make a pull request. There may have been some reasons that might make
it impossible for this to ever make it into the core for instance
(therefore I would be wasting my time trying to update this code to
Joomla 3.0)
[mailto:joomla-dev-general@googlegroups.com] On Behalf Of Marius van
Rijnsoever
Sent: Sunday, November 18, 2012 1:36 PM
To: joomla-dev-general@googlegroups.com
Subject: Re: [jgen] Joomla! exodus?
On Thu, Nov 15, 2012 at 10:55 PM, Andrew Eddie <mambob...@gmail.com> wrote:
> As for the GSOC code, what's stopping you from making a pull request?
There was a working concept for Joomla 1.6 that was planned for inclusion.
It would be great to know why it was not included before I make a pull
request. There may have been some reasons that might make it impossible for
this to ever make it into the core for instance (therefore I would be
wasting my time trying to update this code to Joomla 3.0)
Thanks, Marius
--
You received this message because you are subscribed to the Google Groups
"Joomla! General Development" group.
To post to this group, send an email to joomla-dev-general@googlegroups.com.
To unsubscribe from this group, send email to
joomla-dev-general+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Not sure. Given the change to bootstrap and jquery any previous status for
or against is probably moot. I personally have no problem with frontend
editing.
On Sunday, 18 November 2012, Marius van Rijnsoever wrote:
> On Thu, Nov 15, 2012 at 10:55 PM, Andrew Eddie <mambob...@gmail.com<javascript:;>>
> wrote:
> > As for the GSOC code, what's stopping you from making a pull request?
> There was a working concept for Joomla 1.6 that was planned for
> inclusion. It would be great to know why it was not included before I
> make a pull request. There may have been some reasons that might make
> it impossible for this to ever make it into the core for instance
> (therefore I would be wasting my time trying to update this code to
> Joomla 3.0)
> Thanks, Marius
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com <javascript:;>.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com <javascript:;>.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
This blog post came across my twitter feed today - it's actually VERY appropriate and would benefit EVERYONE IN THIS THREAD to take 15 minutes out of their day to read.
FWIW, one of the goals Kyle has in mind with the JUX work is front end
editing. He's tweeted some mockups of what he'd like to see and some
inspiration for the look, but that's as far as it's come. It's going to
take more than template styling to make it work. That said, I haven't seen
the GSoC code (did I miss the link in the thread somewhere?), but would be
interested to see how well it might actually apply here and now.
From: Andrew Eddie <mambob...@gmail.com>
Reply-To: <joomla-dev-general@googlegroups.com>
Date: Sunday, November 18, 2012 1:39 AM
To: "joomla-dev-general@googlegroups.com"
<joomla-dev-general@googlegroups.com>
Subject: Re: [jgen] Joomla! exodus?
Not sure. Given the change to bootstrap and jquery any previous status for
or against is probably moot. I personally have no problem with frontend
editing.
GSOC = google summer of code
Regards
Andrew Eddie
On Sunday, 18 November 2012, Marius van Rijnsoever wrote:
> On Thu, Nov 15, 2012 at 10:55 PM, Andrew Eddie <mambob...@gmail.com
> <javascript:;> > wrote:
>> > As for the GSOC code, what's stopping you from making a pull request?
> There was a working concept for Joomla 1.6 that was planned for
> inclusion. It would be great to know why it was not included before I
> make a pull request. There may have been some reasons that might make
> it impossible for this to ever make it into the core for instance
> (therefore I would be wasting my time trying to update this code to
> Joomla 3.0)
> Thanks, Marius
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To post to this group, send an email to joomla-dev-general@googlegroups.com
> <javascript:;> .
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com <javascript:;> .
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
-- You received this message because you are subscribed to the Google Groups
"Joomla! General Development" group.
To post to this group, send an email to joomla-dev-general@googlegroups.com.
To unsubscribe from this group, send email to
joomla-dev-general+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/joomla-dev-general?hl=en-GB.
On 19 November 2012 10:29, Donald Gilbert <dilbert4l...@gmail.com> wrote:
> This blog post came across my twitter feed today - it's actually VERY
> appropriate and would benefit EVERYONE IN THIS THREAD to take 15 minutes
> out of their day to read.
Thanks Don. Pretty much sums up a lot of the pro's and con's we've already
been going over and it's good to realise there is no perfect answer, just
degrees of compromise.
<michael.bab...@gmail.com> wrote:
> FWIW, one of the goals Kyle has in mind with the JUX work is front end
> editing. He's tweeted some mockups of what he'd like to see and some
> inspiration for the look, but that's as far as it's come. It's going to
> take more than template styling to make it work. That said, I haven't seen
> the GSoC code (did I miss the link in the thread somewhere?), but would be
> interested to see how well it might actually apply here and now.
> From: Andrew Eddie <mambob...@gmail.com>
> Reply-To: <joomla-dev-general@googlegroups.com>
> Date: Sunday, November 18, 2012 1:39 AM
> To: "joomla-dev-general@googlegroups.com"
> <joomla-dev-general@googlegroups.com>
> Subject: Re: [jgen] Joomla! exodus?
> Not sure. Given the change to bootstrap and jquery any previous status for
> or against is probably moot. I personally have no problem with frontend
> editing.
> GSOC = google summer of code
> Regards
> Andrew Eddie
> On Sunday, 18 November 2012, Marius van Rijnsoever wrote:
>> On Thu, Nov 15, 2012 at 10:55 PM, Andrew Eddie <mambob...@gmail.com>
>> wrote:
>> > As for the GSOC code, what's stopping you from making a pull request?
>> There was a working concept for Joomla 1.6 that was planned for
>> inclusion. It would be great to know why it was not included before I
>> make a pull request. There may have been some reasons that might make
>> it impossible for this to ever make it into the core for instance
>> (therefore I would be wasting my time trying to update this code to
>> Joomla 3.0)
>> Thanks, Marius
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Joomla! General Development" group.
>> To post to this group, send an email to
>> joomla-dev-general@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomla-dev-general+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To post to this group, send an email to joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To post to this group, send an email to joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
