Designing for a community of users can be very different from designing for oneself. One must consider not only the differences in taste, but must also anticipate different and unexpected uses for your product, and don’t forget that when designing for the community, differences in skill level must also be considered. None the less, when approached in the right frame of mind, designing for the community can be extremely rewarding.
This is how it all started…a few years ago when I was fortunate enough to attend my youngest cousin’s wedding. In fact, 8 out of 12 of us cousins were there! It was a great time to fill in the family tree with missing offspring and their birth dates, so I brought my laptop to the reception. My aunt made more than a few corrections to my ‘facts’ and everyone wanted to see what I had found out about our Italian ancestors. At the end of the evening several family members asked if I could send them a copy of our family tree.
(This is a a typical rootspersona panel)
I decided to do one better and setup a family website, and since I am a BIG fan of WordPress, I looked at what plugins were available at the time. None of them did everything I envisioned, however, and since I am a true GEEK, I decided to write my own. Thus was born rootspersona.
Once I finished the first cut, I realized, “Hey, I could share this.” Little did I realize what that meant for the design.
“I originally wrote rootspersona for me…”
A Flexible Design for the Community
When designing a WordPress plugin with others in mind, the first thing to consider is “will it work with other (some? most? all?) WordPress themes”. That meant that charts had to fit in columns of different sizes, users needed to be able to override the color schemes, and any CSS critical to the functioning of the page had to take precedence over the CSS defined for the theme.
“I was perfectly happy with my brown on blue color scheme, but once I decided to share rootspersona that meant it had to work with more than one theme.”
It was impossible, of course, to test with ALL themes, but by picking a few with different layouts, I thought I had covered my bases. Fortunately I had a helpful group of users who were willing to point out the flaws in my logic. Most of the issues revolved around defaults that weren’t universal to ALL themes. Rootspersona uses styles to define the layout of the charts and family group sheets, and funky defaults defined by a theme can result in funkier results.
(Custom styles became a requirement)
By using CSS selectors with the right level of specificity, I was able to insure that the styles required by the plugin for layout took precedence over those defined by the theme, while still respecting the theme’s choice of styles for appearance. Later releases provided options for the user to define the colors and backgrounds used byrootspersona that aren’t defined covered by a themes style sheet. . As an example, I thought a frame around a portrait was pretty cool, but it didn’t work with all themes.
A Comprehensive Design for the Community
I never really got Descendency Charts; I just don’t find the vertical layout easy to read, especially if I need to scroll. However as rootspersona started to take off, it was the number one request for enhancement. A little research revealed it to be a pretty standard genealogy chart, and I realized that if I wanted my plugin to be used, it had to be more comprehensive. I didn’t use them, but it still had value to the community that was building around the plugin.
“As rootspersona started to take off, Descendence Charts topped the list of enhancement requests”.
I realized I had to be more aware of what was expected in a tool of this type, and design the features of the plugin accordingly.
A Robust Design for the Community
When I first wrote rootspersona, I had about 300 people in my tree. The system used XML files to store the data, which was fine for my needs. When others started using rootsperson, I discovered:
1. Not everyone’s file permissions were set the same – many users didn’t have write permissions on their server’s file system.
2. Some users wanted to use rootspersona to present 2000+ ancestors!
3. Not everyone’s experience with WordPress empowered them to debug an issue.
One case in particular comes to mind. I had designed based on the concept of a ‘parent page’, the roots page from which every other persona page could be accessed. In my own case, this was a page with a picture of each grandparent, and a link to their persona page. I anticipated each site owner deciding best how that would work, so I didn’t define a default parent page, relying on the user to understand and define their own. What REALLY happened was that most users left the defaults (no parent page) and ended up with hundreds of WordPress pages, all springing from the front page. If a theme created a menu with all root pages (most do), the menu could scroll for miles! Not to mention the impact on site performance.
Designing for the community meant I had to consider typical usage patterns for the plugin…The result?
1. I replaced the file based design with a database design. This gets around any file permission issues and improves performance for large files.
2. I removed parent page as an option and created one by default that in MOST themes won’t display in the menu. This eliminates panic and improves performance.
3. I added code to detect WordPress and PHP settings that might prove troublesome and offer a warning message to user. At least the plugin doesn’t get blamed as much for non-plugin issues.
These are just a few of the changes that needed to be made to rootspersona to make it more robust.
I’m a Software Designer with a passion for amateur genealogy. Unfortunately I don’t know any better than to mix the two in potentially explosive combinations. 25 years of software experience has allowed me to work in myriad fields, including travel, health care, banking, and shipping. I currently call Matthews, NC home, but one more pet and I swear. Contact me at http://twitter.com/ed4becky or http://ed4becky.net