A presentation at PHP Community Conference in in Nashville, TN, USA by Drew McLellan
PHP Community Conference 22nd April 2011 Drew McLellan edgeofmyseat.com grabaperch.com -THE ORIGINAL- HYPERTEXT PREPROCESSOR
EVERY LINE OF CODE
-CAN HAVE A-
DIRECT IMPACT
ON USERS This is what I’m talking about today
DESIGNING SOFTWARE
FUNCTIONALITY -IS NOT - ENOUGH Providing functionality is a starting point. Yes it has to be usable. But it also has to be USED. Dusty software == failure.
REWIND Let’s rewind. Perch is a small PHP and MySQL based CMS. It’s been developed as a commercial product. I’m going to be talking about my experience developing it. To share experience, not sell to you!
DUD E!
LIKE WHAT ABOUT
DRUPAL? WAIT! Why a PHP CMS?! There are a lot of PHP CMSs. Drupal, Wordpress, Joomla... opensourcecms.com lists 250 of them. But we keep coming across experiences like this:
“ With Wordpress (don’t even get me started on Drupal), the learning curve was very high, requiring my clients to learn about posts versus pages versus custom post types. ” This story is very common. Lots of capable software available, but FUNCTIONALITY IS NOT ENOUGHT. People find their clients can’t use it.
DOZENS OF
OPTIONS MILLIONS OF
USERS Just because a lot of similar things exist, it doesn’t mean the market is too crowded.
DIFFERENT This applies to Open Source projects as much as commercial products. Don’t be afraid of finding a new way to solve a problem that has already been solved.
LIGHTWEIGHT
PHP CMS
FOR SMALL WEBSITES We decided to go ahead. Focussing on a market of web designers building small sites for their clients. Portfolios, restaurants, guest houses, clubs, places of worship.
LISTEN U P! CLASS IN SESSION I’ve split this up into lessons we’ve learned.
DIFFICULT
PROBLEMS
Support will kick your ass. Jason Fried, 37signals http://www.extractable.com/blog/?p=58
Helpspot really saved
our ass when it came
to support.
Todd Dominey, SlideShowPro
http://5by5.tv/bigwebshow/24
SUPPORT
INVOLVES
MANY CUSTOMERS
ARE INEXPERIENCED When it comes to installing and deploying PHP apps - or any. Typically just HTML, CSS, FTP users.
THEY NEED
A LOT OF
SUPPORT
We're a service-based company. We don't have time to deal with a lot of support.
EACH LICENSE SOLD 30 MINUTES OF SUPPORT TIME Financially, each license has max 15 mins support. Of course, that’s not the reality
REDUCE
SUPPORT REQUESTS We needed to find ways to make sure that this was actually profitable. That’s important for us commercially, but it’s also the sort of thing that’s important for OSS. How often does a “strong community” == “hard to use software”.
EVERY REQUEST SHOULD BE
UNIQUE No question should need to be asked twice - every request should be unique
SUPPORT
YOUR OWN
SOFTWARE Developers should support their own software Then you’re exposed to the important problems. Helps to prioritise what to work on. The bugs causing users issues are more important than anything else.
WILL THIS FAI L?
Some fixes can be as simple as microcopy
This used to be a very common support request.
The change of wording eliminated this request almost entirely. The next step is validation on the license key format.
ALL CODE BREAKS. GREAT CODE
BREAKS WELL Anticipate when the code will fail and design for it. This is important in uncontrolled environments like other people’s hosting.
NOT ALL ATTEMPTS
ARE SUCCESSFUL It doesn’t always work as planned
SPEED OF RESPONSE
IS THE MOST IMPORTANT
THING
TECHNICAL PROBLEMS
cult problems are wet ones. Technical problems are hard too.
PHP5 AS STANDARD We chose to standardise PHP5 Thinking we’d exclude some people. We considered developing 2 parallel versions. As it turns out this was a non-issue. Any host on PHP4 these days o " ers upgrades.
WE WOULD LOVE
PHP5.3 Particularly for Phar support. Easier deployment
THE FAILED PROMISE OF SQLITE We wanted to use SQLite to make configuration easier It actually makes configuration harder. DB needs to be protected or outside the web root. Hard when you don’t control the hosting.
SCHEMALESS
STRUCTURED DATA We store structured data without a schema in MySQL
<perch:content
type=”text”
id=”heading”
label=”Main heading”
required=”true” />
TABLE OF KEY-VALUE PAIRS
TABLE OF KEY-VALUE PAIRS
SCALES UP
WELL
CAN BE
FILTERED WITH
SQL
BIG BLOB OF
JSON
STORE ANY SHAPE DATA IN ONE ROW EXTREMELY SIMPLE
CONTENT HAS TO BE FILTERED IN PHP NATIVE JSON LIBRARIES
ARE NOT YET UNIVERSAL
CREATE TABLE perch_contentItems (
contentID int(10) unsigned NOT NULL AUTO_INCREMENT,
contentKey varchar(255) NOT NULL DEFAULT '',
contentPage varchar(255) NOT NULL DEFAULT '*',
contentHTML longtext NOT NULL,
contentNew tinyint(1) unsigned NOT NULL DEFAULT '1',
contentTemplate varchar(255) NOT NULL DEFAULT '',
contentMultiple tinyint(1) unsigned NOT NULL DEFAULT '0',
contentAddToTop tinyint(1) unsigned NOT NULL DEFAULT '0',
contentJSON mediumtext NOT NULL,
contentHistory mediumtext NOT NULL,
contentOptions text NOT NULL,
PRIMARY KEY (contentID),
KEY idx_key (contentKey),
KEY idx_page (contentPage)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
SO, UM, HOW'S THAT WORKING OUT FOR YO U? It’s not ideal! The original requirement of storing schemaless data works!
NON-NATIVE JSON IS SLOW We use the PEAR JSON libraries if native JSON isn’t installed. It’s really slow for the history stack. The more content, it gets exponentially slower.
QUERYING ACROSS TABLE COLUMNS
SO WHAT IS
GOOD
ABOUT IT?
It solved the initial requirement.
Queries are really simple - important on over-loaded shared servers.
{ “heading”: “Foo”, “date”: “2011-04-22 10:00:00” } We were storing data like this... Doesn’t take much of a leap to think we can store multiples....
[ { “heading”: “Foo”, “date”: “2011-04-22 10:00:00” }, { “heading”: “Foo”, “date”: “2011-04-22 10:00:00” } ]
[ { “_rev”: 1300447544, “_content”: { “heading”: “Bar”, “date”: “2011-04-22 10:00:00” } }, { “_rev”: 1293968747, “_content”: { “heading”: “Foo”, “date”: “2011-04-22 10:00:00” } } ]
SIMPLE, EFFECTIVE
HISTORY STACK This very simply enabled us to create a history stack, and implement an UNDO feature.
THEORISING IS EASY NOTHING BEATS EXPERIENCE Every solution has its pros and cons. Ultimately you have to pick one and go with it. We anticipated small sites with low content volumes so went with JSON People are building SIMPLE sites with Perch, but not always SMALL. We may have to revisit, but we can migrate architectures with a script. Yay for scripts.
RUNNING PHP EVERYWHERE
IS HARD
WE ' RE USED TO CONTROLLED PLATFORMS We're used to developing on controlled platforms and deploying to controlled platforms We specify what version of PHP. Configure INI options. Install libraries required.
ALL BETS ARE OFF As soon as you give people code to run in their own environment, all bets are o "
WINDOWS IS WEIRD
MIGRATING
BETWEEN
FILESYSTEMS
cult problems are wet ones. Technical problems are hard too.
WYSIWYG
Nice compromise - toolbar so you don’t need to remember codes, but no filthy HTML.
But my clients must have an editor like Wor d! People are weak. WEAK! Be strong with your clients!
IT ' S NOT OUR PLACE TO TELL PEOPLE HOW TO WORK If they want to give their client a WYSIWYG editor, so be it. All we can do is give them good, sensible defaults based on our own experience.
EDIT IN PLACE
HELP CUSTOMERS
SERVE THEIR
CLIENTS
IDENTIFY YOUR
CUSTOMERS ' PROBLEMS Work out what will make their lives easier, but also make them a hit with their clients.
CONFIDENCE
EVERY FIELD
help=”Use the teacher’s initials from the timetable.”
DRAFTS PREVIEW UNDO We designed features to help give nervous clients confidence
FUNCTIONALITY -IS NOT - ENOUGH
LEARN TO ACCEPT
WHEN USERS ARE HAVING
TROUBLE
REALLY GREAT DEVELOPERS SOLVE PROBLEMS It’s not just about implementing features. Even if there is a solution if people are not finding or understanding it the solution is still broken.
YOU CAN'T
WIN EVERY USER Know your own strengths
I love the little cms but the one thing I was expecting to get is a license for multiple domain,... if you guys can help with that you will earn a big customer,.. and as of right now I already found 2 more cms just like yours at a lower price but what they take a away is in the interface design,.. (which I could careless about it) but you guys still my number 1 option but if you guys can give me a break on that little part for licensing multiple domains that will be very much appreciated,..
EVERYONE
WILL GET IT And that’s fine. In fact it’s good. The worst thing to happen is have a product so bland that no one can object to it.
THANK YO U!
Perch is at grabaperch.com Slides: http://lanyrd.com/2011/phpcomcon
On most things, I’ am
@
drewm
Know your own strengths
QUESTION S?
The following resources were mentioned during the presentation or are useful additional information.
On his personal blog.
Here’s what was said about this presentation on Twitter.
