[drupal-devel] re: that node design mock-ups.

[Chris Messina]

Thought this might interest you: http://blog.simon-cozens.org/6785.html


On Fri, 14 Jan 2005 10:10:45 -0800, Chris Messina
<chris.messina at gmail.com> wrote:
> No problem. Go read my reply: http://drupal.org/node/15506#comment-25366
> 
> :)
> 
> Chris
> 
> 
> On Fri, 14 Jan 2005 14:30:23 +0100, Bèr Kessels <berdrupal at tiscali.be> wrote:
> > Hi,
> >
> > Because i do not believe in telling others what they should do, I started the
> > node-redesign mock-up in the way I think it needs to be done: Bottom-up.
> > (http://drupal.org/node/15506#comment-25337_
> > Chris, I really hope you do not mistake my comments for criticism, or as
> > working against your project. In contrary, I am merely trying to help this
> > project move forward.
> >
> > Drupal has a huge difficulty: its modularity. That has prevented us to make or
> > fix the UI in a good way. The modularity dictates us to make changes to the
> > UI structural, not on a per-case basis. That actually goes for all changes:
> > They cannot be on a per-case basis, but need to be somehow structural.
> > The places where that has been done, are in fact the places where problems
> > start occurring; those places will become inconsistent.
> >
> > A slightly off-topic example of this happened to me yesterday: a client of
> > mine phoned me about wanting to change something to the comment settings. And
> > he simply could not find the comment settings. That is because he expected
> > all site settings to be under administrate > settings. But the comment
> > settings are not there, no, they are inconsistently placed under a tab on the
> > comment-moderation page!
> >
> > I really want to avoid introducing yet another amount of possible
> > inconsistencies, by designing a page for each node-type, each node-type in
> > each case, hell, even each node-type for each role, in each case. Because it
> > is not so that they *can* look different for each site, each role, each node
> > type, they simply *will*, eventually appear different. That's where we have
> > the nodeapis for: To make them different for each case.
> >
> > This all dictates we take this project structurally, start bottom up: What can
> > nodeapi do, where can it do that, what can appear, what not etc.
> > The only thing that is required, ATM is the title, all other elements might
> > (and thus eventually will) appear or disappear.
> >
> > Bèr
> > --
> > | Bèr Kessels | webschuur.com | website development |
> > | Turnhoutsebaan 34/3 | 2140 Antwerpen | België |
> > | IM: ber at jabber.org.uk | MSN: berkessels at gmx.net |
> > | pers: bler.webschuur.com | prof: www.webschuur.com |
> >
> >
> > --
> > Regards,
> >  Bèr
> > --
> >  [ Bèr Kessels | Drupal services www.webschuur.com ]
> >
>