[TYPO3-hci] 4.1 = menubar/iconbar/dashboard; lets go!

Maximo Cuadros mcuadros at gmail.com
Wed Oct 11 12:40:28 CEST 2006


Hi,  Kasper, this is the screencast:
http://t3.mcuadros.es/fileadmin/ext/DojoWebModule.html

I post it in another thread.

Best regards.

On 10/11/06, Erich Althaus - CS2 <erich.althaus at cs2.ch> wrote:
> Hi there
>
> > We could also decide that the Web>Page module becomes Web>Pagetree?
>
> Hmmm? I think one of the Problems the End Users have is the Thing that they are not able to make the Link that the Modules are not Functions, only different Views. I think this is one of the Points which irritates them the most.
>
> That's why I decided to move those views directly to Content. Then it's clear where those infos belong to.
>
> In actual BE when clicking on Web>Page, it does not show Pagetree, it shows Pagetree with a View of the Page. Same in Web>List, this shows Pagetree with List View. Therefore the Naming is correct, on my point of view.
>
> Kasper, do you haven a visual Example (Screenshot) what you understand under Word "Dashboard"?
>
> Greets and Thx
>
> Erich
>
> -----Ursprüngliche Nachricht-----
> Von: typo3-team-hci-bounces at lists.netfielders.de [mailto:typo3-team-hci-bounces at lists.netfielders.de] Im Auftrag von Kasper Skårhøj
> Gesendet: Mittwoch, 11. Oktober 2006 12:17
> An: TYPO3 human computer interaction team
> Betreff: Re: [TYPO3-hci] 4.1 = menubar/iconbar/dashboard; lets go!
>
> Thanks Patrick!
>
> I'm happy to read Erich struck something!
>
> > 1- The highlight (for me...) is the fact that the page tree (and
> > Filelist) are written, easily selectable and visible.
>
> I have decided to add yet an area: The tabbar. So we have menubar/
> iconbar/tabbar. Iconbar and tabbar are only shown if there are
> content in them of course.
>
> In the tab bar we can place tabs linking to theoretically anything,
> but by default we can install a link to Web>Page and File>Filelist.
> We allow alternative namings.
>
> In the right side of the tab bar I want the actual running module to
> install things with AJAX. This could be tabs to submodules as Erich
> suggest. Or for say the Doc module it could be buttons like "SAVE"
> "CANCEL" etc.
>
> With this, Erichs suggestion can be implemented, but the framework is
> more generally able to host other usages for other needs extensions
> will have.
>
> >
> > Pagetree (as we almost call it) is so much better than Web->Page as
> > it's
> >   straight forward, use the "real" name and is for most editors, the
> > central point of TYPO3.
>
> We will allow people to put an alternative name on the tabs.
>
> We could also decide that the Web>Page module becomes Web>Pagetree?
>
>
> >
> > 2- I'm not sure for the clipboard in case of a large >200 pages
> > Pagetree. We're used to normal apps with Edit->Paste so maybe
> > Clipboard
> > is a good contender for the application bar (Kasper's horizontal bar).
>
> The trick to make the new design work is using an IFRAME to run what
> was previously in the bigger framesets "content" frame. Hence, I see
> no way we can have drag-n-drop across frames into a clipboard. The
> idea is nice though but should be implemented inside the frames
> themselves.
>
> >
> > 3- The view from Eric mock up is for no apparent reason more
> > temptating
> > to use. I never used the view/magnified glass available in the last 3
> > years but with the tab it's more likely I would use it. Maybe it's the
> > fact that it's almost instantly showing(since it's just a mock up) and
> > that give me this impression of usefulness suddenly...
> >
> > 4- The faux-spotlight menu showned in Kasper's video could possibly
> > replace the old "Search string/Show record" and then make the editing
> > area less packed. (see the box in list view in Eric's work)
> >
> > 5- We must bring the Undo/history feature easier to reach. The
> > thing is
> > that we have Versionning that also kind of compete in the same area.
> > This is a tab or section that needs to be further analyzed with people
> > that never used TYPO3.
>
> We need to wait with this for a later version because its all about
> what is _inside_ the new framework of menu/icon/tab etc. I want to
> create that framework first.
>
> However, its important to have these visions posted already because
> we must make sure our new framework supports with a high possibility
> the future re-organizations of things to make other parts more
> userfriendly!
>
>
>
> >
> > 6- Help/About/Doc: Mac and Windows used to have the menu item Help or
> > About that consist of those. So maybe a straight Help menu could
> > effectively group together:
> >    About this server
> >    About modules installed
> >    Documentation/manuals
> >    WebStaff help center (custom link)
> >
> > It should be easy for admin to add links there relative to the use of
> > their site. I'm thinking about some pages under a sysfolder with
> > How-to
> > or even links to some intranets docs in a corporate environment.
>
> It will be configurable enough for all of this.
>
> >
> > Maybe the Help menu could also be the host for some reports, logs and
> > statistics.
>
> Could be - or the dashboard! This is where I imagine such applications.
>
> Look at Joomla; They have a default screen with such reports
> including a nice matrix of links to various functionality. We should
> ahve the same - but in a dash-board fashion that can be customized.
>
> >
> >
> >> (I understand that you feel the old backend was good enough for
> >> admins.
> >> For 4.1 it will definitely stay as an option but we should be open to
> >> improvements to the new menu/icon concept that even admins like to
> >> work
> >> with in terms of efficiency)
> >
> > One thing that we also should keep in mind is that all those fine
> > personalizations should be lockable so the admin still get complete
> > control if he wants standard looking BE.
>
> Got it.
> I plan to offer saving them to XML files which can even be
> distributed in extensions - a first step to having predefined "Roles"!
>
>
> >
> > As a rule of the thumb must be: What is not possible to change for
> > a BE
> > user should be invisible. Here I'm referring to the present User-
> > >Setup
> > where users can still see stuff he shouldn't.
> >
>
>
>
>
> >
> >>> http://www.tragamin.com/t3_be/Home.html
> >
> > Eric, that's fantastic that you did that so fast. I mean, I'm someone
> > who need stuff from others to dig deeper and with your mock up I was
> > able to describes ideas I had for a long time. Thanks for that. And...
> > same for Kasper. It's sadly easier to comment than do the actual
> > coding
> > but we should be able to get it right with the eyeballs in this group
> > and the help of few new people not used to TYPO3.
>
> I have two roles for this release:
> - Create a framework that facilitates the possibilities anyone wants
> (like Erics and Tapios ideas) [Obligation as a core developer]
> - Solve the problems of my clients. [Personal itch]
>
> Thats it, no more, no less.
>
> - kasper
>
>
>
>
>
>
> >
> >
> >> "Necessity is the mother of invention"
> >
> > Ah the Mothers of Invention...what a musical group.  ;)
> >
> > Patrick
> > _______________________________________________
> > TYPO3-team-hci mailing list
> > TYPO3-team-hci at lists.netfielders.de
> > http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-hci
>
> - kasper
>
> "Necessity is the mother of invention"
> -------------------------------
> kasper2006 at typo3.com | +45 20 999 115 | skype: kasperskaarhoej |
> gizmo: kasper_typo3
>
>
>
>
>
> _______________________________________________
> TYPO3-team-hci mailing list
> TYPO3-team-hci at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-hci
>
>
> _______________________________________________
> TYPO3-team-hci mailing list
> TYPO3-team-hci at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-hci
>



More information about the TYPO3-team-hci mailing list