Posts Tagged ‘Drupal’

drops_05Not having a wonderful time with Drupal. Dug a great hole, leapt into it, with great travail and the aid of some last-semester techno-friends, climbed back out. I have a way with problems beyond my current ability to solve, and Drupal offered a number of open doors straight to them. At one point I declared “I’M A PROGRAMMER NOT A WEB DESIGNER” and on some simpleheaded level this may be true but what I meant was, stop making my crazy with both the websense and the programmersense. I found that Drupal required both sensibilities which is, I believe, why I went briefly to crazy world. Trying to figure out if the problem at hand, say, needing to create the node for an image before attaching it to my mosaic node, was superficial or complex took a lot of system resources. Or which content was spoken of as external-linkable. Or how the entirety of views_slideshow works. The good news is that I sure have the hang of downloading, unpacking, and installing the modules. I figure any Linux experience is good Linux experience. And I’m grateful for the problems, only because they seem fixed now, and before that because I had to rifle around for tools to help me out. Though I was warned it wouldn’t help, I found phpMyAdmin my best friend sorting out users relative to roles, and ESPECIALLY in locating, by lost-user-ID-number, some dead and orphaned content that was haunting my site.

However. I loved being introduced to Drupal and would love to play more, with guidance. I think it’s an entirely appropriate setting for my collection on mosaics and is value-added relative to any and all websites I have attempted in the past. It could actually encourage me to build the site, to seek content, to enhance content, to organize content, in a way that Dreamweaver does not. It is collection-aware, and it’s the first software I’ve experienced of its kind. I’d like to find out what Drupal regulars feel is the “average” learning curve, or whether Drupal “drop-ins”, infrequent users or one-time-project users, can quantify their learning curve.

Difficult and praiseworthy both is Drupal, but not huge degrees of difference from this setting, WordPress. I still have learning to do here, could potentially mount at least an exhib of mosaics here, with some web content, some text…

Read Full Post »

pace (unit 3)

As for the doing technology part of IRLS675, I say bring it all on. The more the merrier I am. The more practical, the more delightful. Asked to comment on our technology assignments and the pace, compared to IRLS672 to some degree, so far it feels like perhaps 25% less pressure, or 25% less material to cover, (which in a sense is disappointing) but…

I lie because here’s my feeling about it: we’ve covered some pretty big pieces of technology. To get the hang of all that a LAMP server means could take very nice hours of practice and play every week since 672 ended in August. And now we add JHOVE and Drupal. Drupal…I took hours last night I guess you could call it playing, but it’s such a broad canvas that I might call it being distracted. We were given good, clear instruction to stick to the core, not the pretty, but even so…distractions. So I’m not sure if I spent too much or too little time.

Upshot: good pacing so far given other requirements. I always need more time, time, time, to read as the slowest reader on this planet. The more the reading integrates with the practical, applied work, the better. I like the two-track concept for this course, I think.

Read Full Post »


REALLY want to dive completely INTO Drupal megaphonebut there is so much to ABSORB. I walk about my electronic life and see that everything is possibly Drupal. What a great kit.

Read Full Post »

kentstateI chose for unit 2’s assignment 5 to read “Building a Local CMS at Kent State” by Rick Wiggins, Jeph Remley, and Tom Klingler (via Emerald access to Library Hi Tech vol. 24 issue 1).

Kent State interested me because it’s big (14 libraries, 8 campuses) and would therefore present complexity aplenty, I believed, in a project as pivotal as choosing a CMS. It fascinated me that they would have chosen to build their own rather than use something off the shelf. On the other hand, I assumed that they would have a large IT staff in the library system and might therefore routinely devote resources to building their own.

Kent State was ready for a third-generation web system based on users’ desires, not librarians’, and they paid and fed subjects to participate in usability studies. Another sign of largesse borne of largeness. They favored a system that would distribute responsibility for content to a very high degree (and that’s what they ended up with). They desired an ADA-compliant system of classified, not hierarchically arranged, pages with a more professional look, greater automation, and consistency (less “undesired ‘creativity'” on the part of contributors).

This article did not in any way address stresses or conflicts or difficulties–somewhat disappointing in the end. And it did not reveal in any specifics why the off-the-shelf options, including Drupal, failed to satisfy their list of desiderata, simply categorically stating that lots and lots of open source (as that was their preference) options didn’t meet this or that requirement. It was easy to read between the lines that full-bore testing of all the available options was not how they wanted to spend the time they could be building something.

They seem to have poured resources into developing a front end that would enable practically every library staff member to contribute or edit content–this is really interesting, and not a choice I think every work culture would work well with. It means high confidence in a crowd of people, albeit with somewhat locked-down choices; it also means a very granular user interface.

The system was technically a MAMP setup. The project apparently saw simultaneous development of the new site design, the CMS, and content for the site; this is a point where some sense of how this played out on the calendar (not mentioned) would have been helpful and interesting. I cannot believe that obstacles were not encountered.

They also made huge use of two student employees who seem to have served as liaisons, or maybe ambassadors, between the developers and staff and who were responsible for creating both a training manual and context-sensitive help within the system for staff. Again, a large place with a library school on site would have some real talent available in the student pool, so this went believably smoothly.

In general I would have liked to know what was difficult when and, from a project management perspective, how buy-in of staff members was insured. The system itself sounded a lot like what I imagine Drupal and others to be, possibly with more built-in “hall monitor” activity, making sure that the legions of staff involved stay on top of their plots within the greater realm.

Read Full Post »