Nexus and the Joomla revolution
This post is to announce the intended release of Nexus 1.0 at the end of Summer 2011.
Nexus is a software project, I started in order to address the usability issues in Joomla's
administrator application. Many people make the mistake of ascribing the Joomla back
end to the simple notion of a poorly-designed, or "skinned" administrator template.
This is somewhat understandable if one is approaching Joomla as a "web site" and thus
parsing Joomla's behavior and appearance from a "web developer's" i.e. A web site builder's
interpretation. Joomla however, is not a "web site", it can manage the content of a web site
but at it's core Joomla is a web application, composed of a public facing side and a private
back-end. The difference goes way beyond skin deep, the difference divides Joomla architecture
along very carefully prescribed lines. Joomla is a web application first, and that application can
serve some purpose. Unlike other more dedicated CMS's such as WordPress, Joomla is flexible
and that flexibility is unfortunately hidden most of the time.
Needless to say, a "template" is not the origin of Joomla's usability issues and thus it cannot
be a viable solution to them. Joomla's usability issues are built into the logic of it's mangement
component, it's apparent inflexibility is not a true indication of Joomla's architectural capabilites
but merely of one particular use of it's API. That same API can be used a quite a different manner
which would make the back end appear much more user-friendly than it currently does. The crux
of the matter is in fleshing out the logic of just what is "user friendly".
I have come across some core principles which an application must adhere to in order to confer
a subjective experience of "user friendliness" to it.
These principles are:
1.) Visually apparent organization
A.) Spatial proximity of functionally related elements is taken into account when presenting the workspace
2.) Temporally synchronized causation
A.) This can be summed up as "If I do X then Y will happen", this means every interaction produces an
immediate result in one form or another. The user interaction feedback loop is kept as short as possible.
3.) Decision loads are kept to a minimum
A.) A user is presented with the most temporally efficient route to any attempted task completion state.
This means apart from preserving temporal continuity, the user will be asked for the minimum amount
of information necessary in order to effect the desired change.*
4.) The user's contextual perspective Is respected
A.) This means the system performs operations to determine the most relevant way to present information
to the user based on the user's most likely perceptual environment, even if it means more work for the
system.
*If this means that automated processes go into effect behind the scenes to make low-priority decisions
on the user's behalf then so be it. It should go without saying that the behaviour of these automated
processes is configurable as well. For example, all new articles which require (by consequence of a user's
choices) a category to be created first will be set in a programmatically defined queue, the category will be
automatically created and named according to default settings in the configuration, and then the article will be
created and saved in the category. The user does not need to be aware of this, they need only be aware of
their intended effect and the confirmation of it's completion state. All intervening steps may be automated.
These are the core design principles of Nexus. We've worked very hard to make sure all 4 principles are
leveraged in it's design (both infrastructurally and aesthetically).
There's more to come next week much more.
-- Joe
Nexus is a software project, I started in order to address the usability issues in Joomla's
administrator application. Many people make the mistake of ascribing the Joomla back
end to the simple notion of a poorly-designed, or "skinned" administrator template.
This is somewhat understandable if one is approaching Joomla as a "web site" and thus
parsing Joomla's behavior and appearance from a "web developer's" i.e. A web site builder's
interpretation. Joomla however, is not a "web site", it can manage the content of a web site
but at it's core Joomla is a web application, composed of a public facing side and a private
back-end. The difference goes way beyond skin deep, the difference divides Joomla architecture
along very carefully prescribed lines. Joomla is a web application first, and that application can
serve some purpose. Unlike other more dedicated CMS's such as WordPress, Joomla is flexible
and that flexibility is unfortunately hidden most of the time.
Needless to say, a "template" is not the origin of Joomla's usability issues and thus it cannot
be a viable solution to them. Joomla's usability issues are built into the logic of it's mangement
component, it's apparent inflexibility is not a true indication of Joomla's architectural capabilites
but merely of one particular use of it's API. That same API can be used a quite a different manner
which would make the back end appear much more user-friendly than it currently does. The crux
of the matter is in fleshing out the logic of just what is "user friendly".
I have come across some core principles which an application must adhere to in order to confer
a subjective experience of "user friendliness" to it.
These principles are:
1.) Visually apparent organization
A.) Spatial proximity of functionally related elements is taken into account when presenting the workspace
2.) Temporally synchronized causation
A.) This can be summed up as "If I do X then Y will happen", this means every interaction produces an
immediate result in one form or another. The user interaction feedback loop is kept as short as possible.
3.) Decision loads are kept to a minimum
A.) A user is presented with the most temporally efficient route to any attempted task completion state.
This means apart from preserving temporal continuity, the user will be asked for the minimum amount
of information necessary in order to effect the desired change.*
4.) The user's contextual perspective Is respected
A.) This means the system performs operations to determine the most relevant way to present information
to the user based on the user's most likely perceptual environment, even if it means more work for the
system.
*If this means that automated processes go into effect behind the scenes to make low-priority decisions
on the user's behalf then so be it. It should go without saying that the behaviour of these automated
processes is configurable as well. For example, all new articles which require (by consequence of a user's
choices) a category to be created first will be set in a programmatically defined queue, the category will be
automatically created and named according to default settings in the configuration, and then the article will be
created and saved in the category. The user does not need to be aware of this, they need only be aware of
their intended effect and the confirmation of it's completion state. All intervening steps may be automated.
These are the core design principles of Nexus. We've worked very hard to make sure all 4 principles are
leveraged in it's design (both infrastructurally and aesthetically).
There's more to come next week much more.
-- Joe
Last Updated (Sunday, 17 July 2011 01:30)


