[TYPO3-hci] inspiring people to slave, WAS: 4.1 = menubar/iconbar/dashboard; lets go!

Kasper Skårhøj kasper2006 at typo3.com
Thu Oct 12 21:17:25 CEST 2006


Hi there,

> So can you show me the place where we could have read the concept  
> of the new
> "menubar/iconbar/dashboard"?
> Idea: Kasper

First presented by Lasse Nørby in January (first podcast). Others  
applauded it.

> - Concept: Kasper

Was presented as screenshots earlier (11/9, Kickoff mail). Generally  
I perceived that the concept was applauded. Some had variation ideas  
(like Tapio) and I'm making it possible for him to implement.

> - Code: Kasper

My strength was always doing it myself and I got very tired thinking  
about a lengthy process of collaboration. I finally found that my  
contribution was more important than adapting to a process that  
wouldn't inspire me.

Also, doing it myself is a guarantee it will be done, and I didn't  
see a long line of coders around plus that would be the first time  
such a thing fell down from heaven.

Finally, I wanted to have fun with something new like prototype.js  
and scriptaculous

I didn't claim it will be final. But if no one else jumps in, this is  
it.

> Major drawback: Clientside JS - less accessibility

I believe the current 4.0 backend is lost in that respect already.  
There is a much higher interest in AJAX powered features.

BE accessibility is a good idea to think about for 5.0.

Also, I don't mind JavaScript so Xajax is no must for me. I never  
looked at Xajax, intended to. I'm not against it.

>
> If this concept would have been discussed before and a decision for a
> solution would have been made that's regarded by the whole team to  
> be "the
> best" solution it would have been much more efficient.
> There would have been no big difference in the time needed to code the
> solution, maybe there would have been two or three coders working  
> together
> on it.

That would be wonderful, but also a huge surprise for me if that  
happened.

> Without these steps the coder might be lucky if his code works  
> perfectly
> from the start - but in many cases it will just be a waste of time,  
> because
> the coder overlooked some major bugs in his concept.
> The product will be working in a way, but it will just be useless  
> because of
> the conceptual bugs.

If the concept is so bad it will be obvious quite soon and I will  
stop wasting my time.

>
>> It's really not new, that first a concept is needed and then
>> implementation starts. Maybe something for you is new - sorry, I  
>> don't
>> know you - and that is to create one or more functional prototypes.
>> That's the proof-of-concept and the base for further development.
>
> I know what a prototype is ;-)
> But usually you don't start a project by just creating prototypes  
> without a
> detailed planning phase.

I do. Well, I plan a bit, but usually I see it in my head, then make  
it happen. I like it that way.
You don't have to collaborate with me if you prefer another method.


> As you already named it: A prototype is a "proof of concept".
> This means: First you need the concept, then you can prove it with
> prototypes.

We had a concept 11/9

> And usually all these prototypes are based on the _same_ concept  
> and just
> show different possibilities to solve it.

You can make prototype #2 now...

> If you don't do it this way and just start creating lots of different
> prototypes you might never find the real bug, because the code is  
> always
> "correct" and working but the bug is in the concept itself.

We cannot really know what users response to the concept is before we  
can test a prototype.

>
> I don't say there is no concept at all regarding the TYPO3 project.
> But since the start of the development of 4.0 there has been a lot of
> actionism and less discussion.

Now we get blamed for getting things done, thats funny :-)

> One of the results are i.e. the "don't work spaces" - and guess why  
> somebody
> gave them that name ...

Workspaces are very complex technically and I'm not surprised there  
are still problems. These can be solved by everyone by filing patches  
to the bugtracker. We are at least two-three people who can work on  
it from there. On the bug tracker Dmitry told me that among all bugs  
for workspaces, one had a donation offer. The rest can't be very  
important then.

As far as I'm concerned, I will make sure workspaces work for my  
client who requested them in the first place. This might not be the  
case yet, but thats my commitment.


JoH, it's kind of tiring you don't get it, the whole motivation  
thing. Can't you just plainly explain why us core developers have a  
special obligation to solve your problems? Are we your employees? Are  
we morally obliged you think? Why is it not naturally for everyone to  
scratch ones itch? Why is it not natural for a web agency who is  
probably closed to their clients usability problems to not only  
develop concepts for improvement but also sponsor their implementation?

If your itch is that development should work in a more corporate  
fashion I encourage you to make your own team and see how far you get.


Finally, political discussions like these are another good reason why  
I encourage everyone to focus on their freedom to do what they like  
the most.

inspiring people to slave ....erm, sorry, "share!" See the diff?

- kasper


"Necessity is the mother of invention"
-------------------------------
kasper2006 at typo3.com | +45 20 999 115 | skype: kasperskaarhoej |  
gizmo: kasper_typo3








More information about the TYPO3-team-hci mailing list