September 2005 - Development - lists.drupal.org

Re: [drupal-devel] two minor usability issues, introduced recently
by Kobus Myburgh 27 Sep '05

27 Sep '05

> ... Because -i assume- usability reviewers > find it far too much hassle to maintain local devel sites where they can > apply patches. This assumption is absolutely correct, I believe, but in my case it is not practically possible. Having no internet connection at home, and being severly restricted at work (with regards to software that may be loaded) makes this a tough thing to do, so if I want to do this, I need to do this live, and the problem with that is that my host doesn't give me shell access. I have to do everything through some GUI (CPanel). Regards Kobus

1 0

Re: [drupal-devel] forms should reflect settings.php hardcodes
by Kobus Myburgh 27 Sep '05

27 Sep '05

I agree with Ber in principle, however, it should not disappear, but rather greyed out with a notice why it is greyed out, because people will think that Drupal don't support that specific setting. Optionally also import the content of the hardcoded text into the textarea/field before greying it out. That would clear up a lot of confusion in itself if they can see what the predefined content is. Regards, Kobus >>> berdrupal(a)tiscali.be 9/27/2005 11:05 AM >>> Yet another minor issue, that can lead to Mayr annoyances. when a setting is set in settings.php, for example the site slogan, one can still set that slogan in admin/settings. That is strange, and very confusing. A 'hosting provider' such as BygHost, might choose to set harcoded footers 'supported by BygHost'. Users will be very confused why they changed theyr footer, yet the site does not change it. The field of any setting that is harcoded should best dissapear, or otherwise be greyed out. Is that possible with the form API? Ber

1 0

[drupal-devel] two minor usability issues, introduced recently
by Bèr Kessels 27 Sep '05

27 Sep '05

I just upgrded to HEAD and very much suprised to find two rather unfortunate usability iissues introduced: MBstring support? This seems to Just Work, why do I need a collapsed form element telling me it works? Joe user (and I) should not be bothered with form options that are no options. RSS in the global settings is a bit an unfortonate choice. first of all, the amount of items set gloabally: 1) why cant this simply respect the amount-of-nodes global setting? 2) RSS without nodes (in core) is non existing. Thus this is no common setting. Therefore I think this RSS setting should live under settings >> RSS settings, so that contribs can add LOCAL_TASKS or so. The current placement requires any other RSS setting (by a contrib) to be placed elsewhere. Scattered settings are one of the mayor usability issues in Drupal. I really think we must get such changes past at least some usability test before they hit core. PAtches are tested and tweaked on comma, tab and spaces level, yet usability is often simply ignored. Herein lies a great opportunity for the community, IMO. Ber

9 15

[drupal-devel] Re: A collection of usability problems
by Kobus Myburgh 27 Sep '05

27 Sep '05

Ahhh. Thanks, ax! I know of the mailing lists, but what I find troublesome sometime is "what to search for", because I am not sure what the term is for what I am looking for. Thanks for clearing this up. Regards, Kobus >>> axel(a)kollmorgen.net 9/26/2005 10:19 PM >>> On 26.09.2005 12:58, Kobus Myburgh wrote: > Excuse the off topic post here, but I read this here and was > wondering about that many times before. Why can't we do it > /node/edit/4/* instead of /node/*/edit? Would make a lot of little > nagging problems I have to code around all the time go away... :-) http://lists.drupal.org/archives/drupal-devel/2004-05/msg00151.html pp. -- ax Je respecte trop l'idée de Dieu pour la rendre responsable d'un monde aussi absurde.Georges Duhamel

1 0

[drupal-devel] Swiss army knife of RSS feeds - SQL Search patch
by Seth Cohn 27 Sep '05

27 Sep '05

I've uploaded a very rudimentary patch to trip_search (aka SQL search) giving it the ability to generate a RSS feed based on the search. I'll let those with more drupal skills than I have take it further and bring it up to standards, but it's such a simple and easy patch (kudos to everyone who makes it easy to write drupal code) and gives such a great benefit (unlimited customizable RSS feeds of whatever content you want), I want to be sure it doesn't get lost and the right people see it to make those improvements. http://drupal.org/node/32212

2 2

RE: [drupal-devel] Admin theme
by Steven Peck 27 Sep '05

27 Sep '05

If we do put a default admin theme in core, then it should be shipped default off. I find the CS admin theme essentially unusable and a shock when I navigate to it. Admittatly my pool of people I can survey numbers about twelve, but I asked them all and they find that what things they control (blocks, users, content) are disrupted when they navigate away from the look and feel of their current site. One small voice on the -1 crowd -sp > -----Original Message----- > From: drupal-devel-bounces(a)drupal.org > [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Bèr Kessels > Sent: Monday, September 26, 2005 9:24 AM > To: drupal-devel(a)drupal.org > Subject: Re: [drupal-devel] Admin theme > > On Monday 26 September 2005 17:49, James Walker wrote: > > Ok... but I thought one of the big pushes for the admin > theme camp is > > that there would be one true admin theme to rule them > all... so that > > administration of a drupal site was uniform , and thus much > easier to > > document (i.e. where to click, etc) ... then that > information can be > > reliably written in docs (and books) without a "theme depenedent" > > caveat. > > > > or am i missing something 'cause I'm not a usability guy? > > No, I think you might be mmissing the same some others seem > to overlook. I, and other consultants (AFAIK in th thread it > are all small consultants who are "against" an admin theme in > some way) want flexibility above all. > Not one of my sites is the same. Not one site will have the > same admin as another. > > Thus A 'uniform' way is very hard. We really really really > need something that is very flexible, if its up to me. > > And from the comments in here, I get the idea that most > people like the sections idea: select the pages that are > served in an admin theme in the exact same way as we define > paths for blocks. > > So, my idea is that most people in this thread preferred: > A core admin theme. > A UI that allows you to define where theme 'FooBar' will be used. > By default FooBar will be the admin theme. > > Is that correct, people? > > Ber > > >

2 1

[drupal-devel] Does the Forms API give Drupal a model view controller architecture
by Kieran Lal 27 Sep '05

27 Sep '05

Here's a quick overview of Model View Controller architectures that was updated in April 2005. http://www.jdl.co.uk/briefings/MVC.pdf I haven't spent a lot of time thinking about this. 1) Modules represent the model. They are unaware of the view, theme. 2) View - To me there are three stock views, or outputs, in Drupal. The first is just themeless output. The second is the themed output. The third is as an XML-RPC request. 3) Controller-this is traditionally about controlling input. The controller knows about it's views. The question is, does Drupal have a controller, and if it does, is it the Forms API. This is a question that is consistently coming up in comparing Drupal to Ruby On Rails and I'd like to have a solid answer. Cheers, Kieran

7 10

Re: [drupal-devel] A collection of usability problems
by Kobus Myburgh 26 Sep '05

26 Sep '05

> I think it does help. Extending the regexp to also cover node/*/edit and > user/*/edit can't be that hard. Excuse the off topic post here, but I read this here and was wondering about that many times before. Why can't we do it /node/edit/4/* instead of /node/*/edit? Would make a lot of little nagging problems I have to code around all the time go away... :-) Regards, Kobus

2 1

Re: [drupal-devel] A collection of usability problems
by Kobus Myburgh 26 Sep '05

26 Sep '05

I have added the appropriate two pages here[1] and here[2]: I conclude that this usability issue is now closed from the question Dries asked: > Problem #6: quite some people use the front page module. I've never > used the front page module but I'd like to know how it is different > from a static page? The key difference I see is that you ca have a > different front page for anonymous users. If that is the only key > difference, why aren't people using static pages? Something is wrong > here, and I'd like to figure out what. Now is the next step - will this functionality (or similar) be built into Core to finally give this usability problem the death-blow? [1] http://drupal.org/node/32257 [2] http://drupal.org/node/32258 Regards, Kobus >>> kieran(a)civicspacelabs.org 9/23/2005 6:42 PM >>> Creating an admin help page for the front page module with a child page page that includes what you have below would be great. One of the things that is coming back from the user research is the idea of structural administration. Cheers, Kieran On Sep 23, 2005, at 4:06 AM, Kobus Myburgh wrote: > Ok, as promised: > > I have installed front_page module on one of my sites, generated > some silly HTML to use as front page text, and set the settings for > the module. These are my findings: > > (Please note - this is not a review of front_page.module, but > rather a comparison of it with static nodes). > > 1. Frontpage module offers you several options for displaying: > > - For anonymous users: > > * themed - uses your current site's theme to dsplay your > text/code > * full - bypasses your sites theme, uses only your > specified text/code > * redirect - redirects you to another page/node/image/etc. > > - For logged in users: > > * same as for anonymous users > * option to have it the same as for anonymous users > > 2. Static pages can offer you a lot of the above, but, it has a LOT > more administration to do. For example, to implement these features > with static pages, you'd have to: > > 1. Check whether the person is logged in. > 2. Set all the blocks not to display on that particular page. > 3. Must know some PHP to do #1 and to do redirects - can't > use logic in HTML. > 4. No way to disable the logo section of the theme for the > page (e.g. I might just want an enlarged version of my logo with a > few bullets of text on the main page - no other themable objects), > without using another module (I think Gerhard had such a module > where you can have a different logo for the front page). > > Basically, all in all, front_page module makes things MUCH simpler, > and offers more choice than static pages. Static pages for front > pages is too involved for newbies (and lazy admins...) and > front_page module provides a great (and completely functional) > alternative. > > HTH > > Kobus > > > >>>> ITBJDM(a)puknet.puk.ac.za 9/23/2005 10:39:23 AM >>> >>>> >> Problem #6: quite some people use the front page module. I've never >> used the front page module but I'd like to know how it is different >> from a static page? The key difference I see is that you ca have a >> different front page for anonymous users. If that is the only key >> difference, why aren't people using static pages? Something is wrong >> here, and I'd like to figure out what. >> > > I'll take care of this one - giving a complete overview of the > front page module. I will highlight the differences between a > static page and the front page module and then the developers can > determine what to do with regards to this analysis. > > Regards, > > Kobus > > PS: Can we have a list drupal-usability? Or is that overkill? > > > > >

1 0

[drupal-devel] Re: [CS dev] Passing on Spread Firefox, Lincoln's Revenge, Democratica themes
by Chris Messina 26 Sep '05

26 Sep '05

Hey Trae, Makes perfect sense. That's exactly what I intended my theme work to be used for. Basically a CSS Zen Garden in a theme! So yeah, I don't know how to do it, but I would very much like to pass the maintainship of the themes over to you. How do we do that on Drupal.org? Chris On 9/25/05, Trae McCombs <occy(a)occy.net> wrote: > Hi Chris, > > These themes will be rolled into the new CivicSpace theme when we get > the time. The "skins"(as we are calling them -- more on that later) > will be pulled in. > > I am also going to be porting the occy.net theme to be a "skin" for the > CS theme, and we'll be taking submissions, for other included skins(and > layouts) after things get settled down. > > I am very excited about where the CS theme is going to go, it's just > going to take a wee bit of time(not too much more though) to get there. > > Trae > > PS. Just as a note: > > We have a new system we are building into the CS theme. Layouts and Skins. > > Layouts will be "plain" element positions. These layouts can be used as > a base theme if you want to build a "skin" on top of it. > > A Skin for the CS theme is going to be the actual theme, or style. You > should be able to take a skin, and move it to another layout and get a > different layout but with the same colors. > > This might not make sense now, but when we get things polished, and the > documentation(Robin "mozillaman" Monks will be writing) is done, I'm > sure everyone will see the huge benefits. > > Chris Messina wrote: > > Hey all, > > > > I'm looking for a new maintainer for Spread Firefox, Lincoln's > > Revenge, Democratica who can take those original styles and port them > > to the CivicSpace XHTML foundation > > (http://drupal.org/project/civicspace_theme) If you want details on > > this task, let me know. It's just become quite obvious that I don't > > have the time to maintain these themes and it's time for someone else > > to move them forward! > > > > Chris > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: civicspace-dev-unsubscribe(a)civicspacelabs.org > > For additional commands, e-mail: civicspace-dev-help(a)civicspacelabs.org > > > > -- > Trae "occy" McCombs || http://occy.net/ > Founder - Themes.org // Linux.com > CivicSpaceLabs - http://civicspacelabs.org/ >

2 1