An Early Nexus interface mockup
Sunday, 17 July 2011 01:39 | 
Written by Joe Hacobian | 
| 
| 
I wanted to post this early interface mockup from last year (we have since moved to
live production in JavaScript and the interface looks slightly different), the current
interface looks different mostly due to it's emerging state i.e. The various "toolboxes"
are not yet implemented and the widget system is in prototypal form.
Those of you familar with OOP design will know that once you "get it right" in one class
the particular idiosyncracies of the other variants (toolboxes, widgets, etc) can be created
by inheritance and extension/overloading.
So here is a visual example of what is meant by Nexus' "direct visual interaction" environment:
And now here's an annotated version:
Please Note: Widget based interaction system "Lost Wandering" in the Joomla back-end.
Is a mis-mockup, I meant to say: Widget based interaction system eliminates "Lost Wandering" in the Joomla back-end.
In case you're wondering about the behavior of the "Quick Tasks". They are drag and drop based workflow-chain-of-event progressions designed to get you the user from point A (your intention) to point B (the result of your intention) in as little time and frustration as possible, while still observing best-practices in content management. To all the tablet users reading this, sorry tablets, we REALLY tried to include tablet support in this version but it just wasn't feasible.
Come to think of it, have you ever tried to get any meaningful data from a camera or other peripheral onto a tablet device? Forget IOS's issues, it's just plain difficult. That was a huge factor, the lack of hover support (They'll get to it eventually) was another stick in the mud. I'm really pushing to makethe widget system tablet-friendly such that tablet users can at least manage existing content without dealing with Joomla's legacy components.
Stay tuned for more updates... ;-)
live production in JavaScript and the interface looks slightly different), the current
interface looks different mostly due to it's emerging state i.e. The various "toolboxes"
are not yet implemented and the widget system is in prototypal form.
Those of you familar with OOP design will know that once you "get it right" in one class
the particular idiosyncracies of the other variants (toolboxes, widgets, etc) can be created
by inheritance and extension/overloading.
So here is a visual example of what is meant by Nexus' "direct visual interaction" environment:
And now here's an annotated version:
Please Note: Widget based interaction system "Lost Wandering" in the Joomla back-end.
Is a mis-mockup, I meant to say: Widget based interaction system eliminates "Lost Wandering" in the Joomla back-end.
In case you're wondering about the behavior of the "Quick Tasks". They are drag and drop based workflow-chain-of-event progressions designed to get you the user from point A (your intention) to point B (the result of your intention) in as little time and frustration as possible, while still observing best-practices in content management. To all the tablet users reading this, sorry tablets, we REALLY tried to include tablet support in this version but it just wasn't feasible.
Come to think of it, have you ever tried to get any meaningful data from a camera or other peripheral onto a tablet device? Forget IOS's issues, it's just plain difficult. That was a huge factor, the lack of hover support (They'll get to it eventually) was another stick in the mud. I'm really pushing to makethe widget system tablet-friendly such that tablet users can at least manage existing content without dealing with Joomla's legacy components.
Stay tuned for more updates... ;-)
Last Updated (Sunday, 17 July 2011 09:25)
Serious?
Heh.... hehe...
Well, I'm serious, actually I'm a little bit crazy.
Sane people with no programming experience don't wake up one day and say:
"That's it! I'v had enough of this. I'm going to build it better." and then
proceed to go off and learn how to program, find competent coders, and project
manage, the whole thing.
In fact, this may be a good topic to blog about, then Steve can show up and
vouch for the attitude behind my sig ;-P.
But yeah, it's totally legit, and apparently no-body else is doing it despite
the 2011 date and massive javascript application proliferation.
Heh.... hehe...
Well, I'm serious, actually I'm a little bit crazy.
Sane people with no programming experience don't wake up one day and say:
"That's it! I'v had enough of this. I'm going to build it better." and then
proceed to go off and learn how to program, find competent coders, and project
manage, the whole thing.
In fact, this may be a good topic to blog about, then Steve can show up and
vouch for the attitude behind my sig ;-P.
But yeah, it's totally legit, and apparently no-body else is doing it despite
the 2011 date and massive javascript application proliferation.
That is quite a project you have going there. You must have some serious backing. I will definitely be watching Nexus.
So Joe, how would you describe the Nexus software?
I would describe it as a unified environment for managing the content of a web application.
From the very beginning I was extremely careful to not try to half-ass the architecture out of
a sense of haste. This means we took a while to actually learn how JavaScript works (which is
actually much more rare among web developers than you'd think) due to a very real issue with sites
of substantial size running into JavaScript conflicts when running on the popular AJAX libraries such
as MooTools and JQuery and Prototype and Dojo. JavaScript really enables Nexus to do what it does and therefore we needed to become experts in the behavior of JavaScript.
For a good introduction to JavaScript I recommend Douglas Crockford's lectures on the history of
JavaScript and why it behaves the way it does.
The rest of Nexus uses some quite normal though more application-like programming logic and strategies
to do what it does (we think of Nexus as a unified whole which is itself composed of a component and a set of Plugins and Modules working in concert in order to reliably "synthesize" the common-sense graphical presentation of how Joomla works. So from a web developer's point of view this is not your typical "sunday driving" in PHP, it's more serious both in theory and in practice.
Would you say that it is an abstraction?
Nexus certainly possesses subsystems which perform a high level of abstraction.
In fact, during the course of figuring out how to link the specific Joomla entitiy data such that it would be accessible from the UI layer I decided to separate the two systems i.e. The UI layer composed primarily of JavaScript logic and rendering code vs the Abstraction layer composed of Joomla-specific PHP code which makes short work of finding one's critical "low bandwidth" data quickly and then a secondary mechanism is able to be called in for the detailed "high bandwidth" data.
In the end it's all text data, however you'd be surprised how many fields and parameters are involved
in even a single modern CMS page-load on a substantially content-rich site.
Beyond this, there are systems (still within the abstraction layer) which will enhance the accessibility of Joomla even further. Joomla has been in dire need of a console for a very long time.
The same system which will enable Nexus to talk to Joomla efficiently will enable a console to be functionally efficient(I'm not sure if I'll include that functionality in the Nexus environment though). The really exciting news about such a console isn't that the user can access Joomla's power via a command line, rather the command-parser will have a very simple noun-verb / subject-action structure. The console system will absolutely accept plain utf-8 text files formatted in the to-be-detailed command language, such that you will be able to upload a Joomla configuration script (without having to know PHP or MySQL or any Joomla API calls at all) and setup a Nexus based Joomla site in a matter of minutes complete with the appropriate structure and even sample content of your specification.
This is really exciting news for site integrators which normally build structure and content for clients over and over along very similar patterns. This new console and command parsing architecture
will turn what used to take hours of plodding dull repetition into a minute of waiting and then moving on to more advanced site configuration tasks. However, I'd like to make a note that even though Nexus will use all of these libraries which we're building, the drag and drop Nexus experience and the project known as Nexus will not automatically include the console and command interface for human accessibility due to the advanced and niche nature of the project. The core of Nexus is the graphical
site management component and it's attendant systems.
Would you say that it is an interface?
It has various interfaces and use modalities. So while Nexus is dripping with interface technology
it's also a much deeper engagement with the systems of Joomla in a sincere effort to address the core usefulness and usability issues of the Joomla platform WITHOUT running away into the "CCK mob" or re-writing the content component which we really feel isn't fundamentally flawed at all.
In my view and in the Nexus project, the atomic unity of content is the article, and all additional functionality is added to that basic unit using plugins and modules. Other components will be created to manage media, however they will inject their content (the media that is) into Joomla content articles via integration plugins.
No CCK necessary.
I would describe it as a unified environment for managing the content of a web application.
From the very beginning I was extremely careful to not try to half-ass the architecture out of
a sense of haste. This means we took a while to actually learn how JavaScript works (which is
actually much more rare among web developers than you'd think) due to a very real issue with sites
of substantial size running into JavaScript conflicts when running on the popular AJAX libraries such
as MooTools and JQuery and Prototype and Dojo. JavaScript really enables Nexus to do what it does and therefore we needed to become experts in the behavior of JavaScript.
For a good introduction to JavaScript I recommend Douglas Crockford's lectures on the history of
JavaScript and why it behaves the way it does.
The rest of Nexus uses some quite normal though more application-like programming logic and strategies
to do what it does (we think of Nexus as a unified whole which is itself composed of a component and a set of Plugins and Modules working in concert in order to reliably "synthesize" the common-sense graphical presentation of how Joomla works. So from a web developer's point of view this is not your typical "sunday driving" in PHP, it's more serious both in theory and in practice.
Would you say that it is an abstraction?
Nexus certainly possesses subsystems which perform a high level of abstraction.
In fact, during the course of figuring out how to link the specific Joomla entitiy data such that it would be accessible from the UI layer I decided to separate the two systems i.e. The UI layer composed primarily of JavaScript logic and rendering code vs the Abstraction layer composed of Joomla-specific PHP code which makes short work of finding one's critical "low bandwidth" data quickly and then a secondary mechanism is able to be called in for the detailed "high bandwidth" data.
In the end it's all text data, however you'd be surprised how many fields and parameters are involved
in even a single modern CMS page-load on a substantially content-rich site.
Beyond this, there are systems (still within the abstraction layer) which will enhance the accessibility of Joomla even further. Joomla has been in dire need of a console for a very long time.
The same system which will enable Nexus to talk to Joomla efficiently will enable a console to be functionally efficient(I'm not sure if I'll include that functionality in the Nexus environment though). The really exciting news about such a console isn't that the user can access Joomla's power via a command line, rather the command-parser will have a very simple noun-verb / subject-action structure. The console system will absolutely accept plain utf-8 text files formatted in the to-be-detailed command language, such that you will be able to upload a Joomla configuration script (without having to know PHP or MySQL or any Joomla API calls at all) and setup a Nexus based Joomla site in a matter of minutes complete with the appropriate structure and even sample content of your specification.
This is really exciting news for site integrators which normally build structure and content for clients over and over along very similar patterns. This new console and command parsing architecture
will turn what used to take hours of plodding dull repetition into a minute of waiting and then moving on to more advanced site configuration tasks. However, I'd like to make a note that even though Nexus will use all of these libraries which we're building, the drag and drop Nexus experience and the project known as Nexus will not automatically include the console and command interface for human accessibility due to the advanced and niche nature of the project. The core of Nexus is the graphical
site management component and it's attendant systems.
Would you say that it is an interface?
It has various interfaces and use modalities. So while Nexus is dripping with interface technology
it's also a much deeper engagement with the systems of Joomla in a sincere effort to address the core usefulness and usability issues of the Joomla platform WITHOUT running away into the "CCK mob" or re-writing the content component which we really feel isn't fundamentally flawed at all.
In my view and in the Nexus project, the atomic unity of content is the article, and all additional functionality is added to that basic unit using plugins and modules. Other components will be created to manage media, however they will inject their content (the media that is) into Joomla content articles via integration plugins.
No CCK necessary.
I'm re-posting this question from Paul Ferguson, one of the members of our Los Angeles Joomla Meetup. If you're based in the Los Angeles Area you can check us out via: www.meetup.com/LA-Joomla/
Right then, onto the question Paul had:
"So Joe, how would you describe the Nexus software? Would you say that it is an abstraction, would you say that it is an interface, or would you call it something else. This is interesting. You confirmed my suspicions. I have not goten into joomla much. I just learned how to install it and do a few different things. The thing that struck me about joomla is that it seemed so much more customizable in terms of functionality. With WP you are stuck with what they give you unless you modify Php."
Right then, onto the question Paul had:
"So Joe, how would you describe the Nexus software? Would you say that it is an abstraction, would you say that it is an interface, or would you call it something else. This is interesting. You confirmed my suspicions. I have not goten into joomla much. I just learned how to install it and do a few different things. The thing that struck me about joomla is that it seemed so much more customizable in terms of functionality. With WP you are stuck with what they give you unless you modify Php."