Well, here’s our first weekly Dbasr status report! As I’ve mentioned, I intend to do one of these every week on Sunday or Monday if possible. It’s part of my transparency policy for the Dbasr project, and also to let people who’ve contributed know what we’re doing with their money.
So…what’s new? We’ve raised $430 our first week; not as much as I’d like, but a promising start. We’ve also got two lovely people volunteering to help with the coding! I’m currently trying to document what I’ve got so far and get them up to speed and figure out where their strengths and interests are; more on that to come.
I rewrote Dbasr’s data classes entirely. There’s an abstract class called “Item” and every other class is a child of that. “Item” has one static property — a table name in the database — and each child class updates that property to suit whatever table is associated with that class. When an object is instantiated — like a new Post — it simply retrieves a row from the associated table and populates its property table with each item from that row; the related property name comes from the associated column name.
What does that mean? Well, it means, for example, that whenever you create a new Post object and give it the id of a post in the database, it goes and gets the structure of that table, which might look like this:
- id
- title
- slug
- body
- category
- tag
- status
- user
- dateAdded
And then it gets the right data for each of these, and creates a Post object that has properties id, title, slug, body, etc. Each class is also extended to have a couple of other properties; for example, the “category” for each post is a numeric ID for that category, but when a Post is created, the class also retrieves the name of the post’s category, for ease of use, and dumps it into a property called “categoryName”.
This is much cleaner than the way I was doing it before, where every class had a custom construct. Whenever I changed anything around in the database, I had to make sure to update the associated class; now the class just works with what it’s given, not what it was expecting.
It also reduced the size of the class file from several thousand lines of code to 282. Which is rad.
(I’m a big believer in elegance in code architecture. If I can’t look at my code and figure out how it works, nobody who wants to tinker with it will be able to, either.)
I haven’t added all the classes yet, because I’m still working out the database structure for things like the store, but I’ve got 90% of it done. And having classes to work from is probably seriously 30-40% of the entire Dbasr functionality; most of the eventual template tags will simply be calls to retrieve class properties.
So that’s cool.
I’ve also been wireframing the admin pages. As I mentioned, I’m aiming towards minimalism in the design of the admin section, partially out of my own tastes and partially because Dbasr is meant to be non-intimidating to the casual user. My experience and anecdotal evidence suggests that non-technical users are often frightened by their first look at the WordPress dashboard. (Never mind things like Joomla or Drupal, which resemble the instrument panel of a fighter jet.)
So rather than putting every single admin page into the main sidebar menu, I’m going to put just the categories — Posts, Events, Media, etc. Click on ‘Posts’ and you’ll see a list of posts and a ‘New Post’ button. There’ll also be quick links on the main admin dashboard page.
I’m not 100% sure on this, but I’m going to start that way and do usability testing.
So what’s next? Building the admin control panels, really. When that’s done we’re 60% of the way finished with Dbasr. That said, this is the most daunting process and the one I’ve spent more time attacking in bad, useless, needlessly complex ways for the past couple of years. I’m really trying to pare each admin page down to its most simplistic possible layout. I’m going to split each page into a “basic” and “advanced” section. So if you want to just put up a quick event, you’ll have the basic input elements — venue, date/time, location, etc. But if you click on the ‘advanced’ twisty, you’ll see the option to add media or images to the event, add custom tags, etc.
What do you think? Is this a good way of organizing this stuff?
So expect musings on control panel design this week. My goal is to have at least three of the pages finished and working, if not styled, by next week’s status report, and at least a working prototype of the UI.
Onward and upward!