[consulting] A defense for new users

[John Sechrest]

 % Yeah, actually I am.  I am suggesting that if some new user advocates  
 % work with me we can work together to make some arguments why a new  
 % user task interface should be in core.  


 As we look at interfaces, I think it is important to understand
 that there are many many different levels of users.

 It is clear to me from our discussions on this list that 
 developers and consultants have different issues, and that at least
 some of the developers can not distinguish between what 
 a developer and what developer process is from what a 
 consultant (or implementor) does. In the same way, we have
 many layers beyond that.

 As I have been installing drupal for non-profits, I find that I have
 to deal with 4 types of folks on a regular basis:

 1) Organizational leaders - like directors, who typically are non-technical
    in a huge way. Enough that trying to explain roles and permissions
    is difficult. But they have administrative tasks that they 
    often are responsible for, like being the only full time
    person who can be justified to have the rights to turn on
    and off users from different roles. 

 2) traditional web designers - who don't "get" the CMS process and 
    do not have enough skills to do php coding and are generally
    happy with dream weaver/front page, but now are needing to 
    translate / transfer content from the old site to the new site. 
    And they are the ones who are embedded in the organization
    and will have long term influence on the website. 

 3) Enthusiastic volunteers who are technical - the "newphew" who
    gets enlisted to solve all the tech problems as the default
    support staff for the non-profit, who go around poking at
    buttons and changing things to "make things better"

 4) true new users, who are volunteers to the organization and who
    have never seen a CMS system and don't know what it is,
    but want to make the mission of the non-profit move forward. 


 As an consultant, I have been in situations where each of these
 needed to touch the admin interface at some level. Often non-profits
 will not hire/train people to the right skill level before they
 hand off the keys to the shop. 

 I think we all agree that having a way to make the admin process
 straight forward for the non-drupal administrator is a generall good thing.

 I also think we all agree that there are developmental changes that
 could help this. It includes having the ability to have 
 consistancy across themes and having clearer presentation of tasks
 in a user focused way , instead of a drupal focused way.


 As a consultant, I find that my problems with drupal tend to	
 focus around maintainability:

 1) I find that upgrading drupal is problematic. And while I can
    install a new drupal site in 2-8 hours, I find that I can 
    often install a new site faster than I can get an upgrade
    to be completed. In an upgrade I find:
       a) I still have to touch all of the same areas as an install:
	  1) the modules
	  2) the permissions
	  3) the users
	  4) the theme engine
	  5) the themes

       b) the modules don't always go straight across, so every version
	  upgrade, I have to check to see if the module will
	  work. Because the API is moving and there is no backward
	  compatability, I have to check each and every module
	  and see if I can have all the old functionality that I wanted
	  and see if it is compatable with the new functionality that
	  I want to get. 

       c) Because there is no interface for managing the structure 
	  of the site, I am forced into mucking directly 
	  with the datebase for taking snapshots, and hand editing
	  things to move across. This is not a feature. In a 
	  proper tool, we could have semi-technical web support
	  staff do upgrades by clicking on the interface, but because
	  things are shifting underneath the structure so frequently
	  from release to release, it is not possible to even
	  contemplate building that tool.


    And so for my non-profit clients, I am faced with the need to 
    spend significant amounts of time for upgrades. And I am 
    actually considering rebuilding several sites from scratch,
    because the upgrade path looks so painful. 

	  
   2) There is no interface for downloading modules and installing them.
   The current process of having random tables added and created
   for modules makes the management of modules problematic.

   the core idea that everything is a "node" is a create idea.
   But was we see the developers installing new tables , new structures
   and not using the node structure, we find that things do not 
   generalized. The way that the current user information is 
   packed and stored in the user database is an example of a non-general
   hack, which comes back to bite us. 

   It it truely a shame that it is not true that a node, a page, 
   an event, a group , a list, a gallery are not just all nodes
   using a core structure. It makes long term (multi-year) 
   maintainability harder, because it leads to a fluctuating API
   and a fluctuating set of modules. 

      
   3) It is a shame that you can not get a module that is perfect. 
   When a module is "done" and has all the functionality it needs,
   a maintainer has to stay on-board and maintain it, because 
   the underlaying core is moving. And so as a consultant,
   if I rely on the existance of a module, I may find that
   I have become a developer to support a module which used to work
   just fine, but with new changes, It does not work. The original
   developer has a tool that works for them and does not plan to 
   work on it. And so if I need it, then I am in the position
   of charging my clients to port a module. So I am put in the 
   possition of charing my client for changes brought on by 
   the development process. Which can take small projects and 
   make them too expensive for the client market place that I am
   working in. 

      
  4) modules don't all play with each other. I would like to 
  have the functionality of organic groups and to have 
  node permissions by role. And yet, this does not work.
  And so I have to choose between modules. And again to fix
  the functionality so that the I can get both sets of features,
  I am drawn into being a developer. But this is difficult:
    
    a) my clients often don't want to pay for fixing this type 
     of problem. 

    b) I need to focus on generating revenue, so this is an overhead
    task that takes away from allowing my to make a living
    the way that I am trying to. 

..... 

 Hmmmm. I seem to have stepped into the beginnings of a rant.....

 I will have to pause and see how I can get clear on what I was
 saying. 

 In any case, I agree with Kieran about the need for focusing
 on the user experience from the "new user" point of view,
 but think that we need to be careful to understand who the 
 "new user" really is and what they really are doing. 

 And I hope that the process of working towards new user ease of use
 also leads us to more maintainable drupal sites. 







-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest at peak.org
                                      .   
                                              . http://www.peak.org/~sechrest