I’m starting today a complete rebuild of the admin interface, which may
make Hercule’s works look like a piece of cake.
The goal is not adding new functionnality, even though I want to try a
few things, but improving usability and make typo more intuitive and
easy to use for the technology impaired user, or sort of.
Before starting the whole process, I’d like to have your ideas, wants,
feedbacks… I can’t promise I’ll take that into account because
sometimes, usability from the developper’s point of view is not the same
thing as from the end user’s one, but I’ll try anyway.
I’ll try to do it the most progressive way, not changing everything at
the same time, but the current admin is such a mess… can’t even say if
I will be able to do so.
I’ve already started to re think the whole stuff from scratch, but I’m
really looking forward your ideas.
Before starting the whole process, I’d like to have your ideas, wants,
feedbacks… I can’t promise I’ll take that into account because
sometimes, usability from the developper’s point of view is not the same
thing as from the end user’s one, but I’ll try anyway.
It would be nice if the sidebar plugins can be grouped so they they can
be
called separately in the main template. I’d like this to use a 3 column
CSS
layout with some sidebars in the left column and others in the right.
be called separately in the main template. I’d like this to use a 3
column CSS layout with some sidebars in the left column and others in
the right.
John, this is not an admin issue. It deals with the way typo displays
the sidebar. And I totally agree with you, being unable to have a 3
columns CSS is a pity, but I think it’s going to be a real big big stuff
for the next version.
If one of the mainteners start to implement this, I’ll do it for the
admin as well, but I do believe they have some other priorities.
On Thu, 2006-07-20 at 17:14 +0200, Frederic de Villamil wrote:
I’ve already started to re think the whole stuff from scratch, but I’m
really looking forward your ideas.
Would a WYSIWYG post editor be out of the question?
-Wade
I’ve been thinking about it for a while actually, and there are lots of
for and against.
I really don’t like wysiwyg editors, but my personnal tates is nothing
when compaired to the amount of users Typo should gain with a wysiwyg
interface.
If we decide to enable one, it means we MUST have an alternate editor
with people being able to choose whether or not they want to use it. I
come from the Wordpress world where adding a rich text interface by
default without any alternative really made a fuss for the 2.0 release,
and they had to make a step back.
There is still an issue : does the rich interface need to be enabled by
default or not ? I believe it depends on another question : we want to
make Typo more user friendly, but do we want him to still choose his
friends or not ?
I have some code that I started out with for using FCKeditor in the
admin
area that can be turned off and on via javascript in the posting area.
I
would be glad to share if anyone is interested.
I quit working on it when I found out that FCKeditor doesn’t support
Safari.
TinyMCE works with all browsers and shouldn’t be too different to
integrate. Either way Ruby code to handle file upload would be needed
as I
didn’t get to that.
…and thus we continue to grow farther and farther away from the
simple blog engine that could.
I’d love to see a plugin architecture so those of use who were
attracted to the lean and speedy aspects in the beginning don’t have
to bulk up on ‘functionality’. Added features draws users though it
has to be said.
If I ever get the time after 4.0 and when life calms down, I’m going
to look at ripping out the excess from a copy to see how light it can
go. I mean I don’t even own an xbox
I’ve been busy, but a belated ‘Woo hoo’ for the speed improvements
Scott.
I’d love to see a plugin architecture so those of use who were
attracted to the lean and speedy aspects in the beginning don’t have
to bulk up on ‘functionality’. Added features draws users though it
has to be said.
I have mixed feelings on this. On one hand, Typo’s pretty clearly
over-complex, at least in some areas. On the other hand, most of the
really painful complexity in Typo has to do with plugin frameworks
:-(.
Fortunately, a lot of the pain that we’ve went through lately should
pay off once we ship 4.0, because we can start removing old cruft.
Pier’s blog_id code will let us get rid of a ton of special-case code
that lurks in the text filter framework. The whole text filter and
sidebar frameworks need to be rewritten to use Rails’s native plugin
support. It won’t be a big change for the plugins themselves, but
we’ll be able to dump a lot of complex (and slow!) infrastructure
code. It’ll be really nice to get rid of components.
A side effect of this is that we’ll be able to dump quite a few of the
sidebars in the trunk out into their own packages. Presumably we’ll
be able to make something like ‘rapt install typo41-sidebar-xbox’ work
seamlessly, although I haven’t played with any of the Rails plugin
tools enough yet.
We can also prune the size of our tree back quite a bit–there’s a lot
of stuff in vendor/ that we can delete and replace with .gem
requirements eventually.
If I ever get the time after 4.0 and when life calms down, I’m going
to look at ripping out the excess from a copy to see how light it can
go. I mean I don’t even own an xbox
I’ve been busy, but a belated ‘Woo hoo’ for the speed improvements
Scott.
On Thu, 2006-07-20 at 17:46 +0200, Frederic de Villamil wrote:
It would be nice if the sidebar plugins can be grouped so they they can
be called separately in the main template. I’d like this to use a 3
column CSS layout with some sidebars in the left column and others in
the right.
I agree. But I’d like to see even more than 2 sidebars be possible.
Think Hemingway (the theme) for instance.
I agree with Frederic, though. That will be a big change.
On Thu, 2006-07-20 at 17:14 +0200, Frederic de Villamil wrote:
Hi list,
I’m starting today a complete rebuild of the admin interface, which may
make Hercule’s works look like a piece of cake.
Awesome!!
I would love to see the preferences system work with plugins (one day…
you’ve got ot start somewhere). The plugins will have to configure
themselves somehow, and allowing them to easily add their preferences
anywhere in the settings pages would be really nice.
I’d also like to see Typo move toward a more traditional preferences
setup, maybe with a hierarchy of tabs. The current 5 mile long form is
a little daunting.
A tab hierarchy could be:
Top-level Tabs:
Editing Appearance Users Plugins New Article New Page
Editing:
Articles Pages Comments Files Categories Text Filters
Blacklist
Appearance:
Sidebar Themes
Thoughts:
I would like New Article and New Page buttons to be on the main page.
They don’t have to be in the tab bar though… Maybe put them in the
upper right-hand corner?
Would Text Filters be considered Plugins?
Anyhow, it would be really nice if it were all modularized so that
re-organizing the settings pages would be a simple job.
On Thu, 2006-07-20 at 12:31 -0500, Steve L. wrote:
TinyMCE works with all browsers and shouldn’t be too different to
integrate.
Moxiecode claims partial support but it’s horribly buggy to the point of
uselessness. I’ve just told my customers to use Mozilla until Apple
fixes getSelection() and contentEditable (they claim that the next
Safari release should have the fixes).
Have you actually used TinyMCE on Safari? Is your experience different
than mine?
thing as from the end user's one, but I'll try anyway.
It would be nice if the sidebar plugins can be grouped so they they
can
be called separately in the main template. I’d like this to use a 3
column CSS layout with some sidebars in the left column and others in
the right.
I agree. But I’d like to see even more than 2 sidebars be possible.
Think Hemingway (the theme) for instance.
It’d be nice if it was an arbitrary number of groups and they didn’t
have to
be “side” bars: could be above the articles, below the articles, or
elsewhere.
I agree with Frederic, though. That will be a big change.
I mentioned this on IRC and Piers said:
My gut feeling is that you could introduce sidebar divs in that
interface
and populate each div, then you get to position the subdivs where you
like
with a CSS if your theme supports it, but it’ll still show up correctly
in
themes that don’t want multiple sidebar stuff…
I have mixed feelings on this. On one hand, Typo’s pretty clearly
over-complex, at least in some areas. On the other hand, most of the
really painful complexity in Typo has to do with plugin frameworks
Well, that’s always the way. Just today I was modifying another CMS at
work, and realized just how tiny and simple it was compared to the
behemoth I had borrowed a lot of the code from. The secret, of course,
is that the new tiny system only had to please me, wheres the behemoth
was built to be configurable to the ever-changing whims of a wider user
population.
I do feel, though, that you should either stabilize and document the
plugin frameworks, or rip them out. At the moment, nobody uses them
because it’s an undocumented moving target, but you have all that
complexity there anyway. I say either lose the complexity, or document
and stabilize it so people will use it and you’ll get some actual
benefit from having it there.
The whole text filter and
sidebar frameworks need to be rewritten to use Rails’s native plugin
support.
