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

• FOR - HUMANS In the purest sense. Not just designing to perform a functional task. To enable users to perform that task SUCCESSFULLY.

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.

THERE 'S ROOM

IF YOU CAN BE

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.

• THE MOST -

DIFFICULT

PROBLEMS

• ARE THE - WET ONES

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

• A LOT OF - ASSES

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

• FIND WAYS TO -

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.

• WHEN -

WILL THIS FAI L?

• Every line of code has the potential to create a support request
• robustness
• di " erent configurations
• clear wording
• when will this fail?

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

• ARE - DIFFICULT TOO We said the most di

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

• TO MOVE TO -

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

• OR - BIG BLOB OF
  JSON

TABLE OF KEY-VALUE PAIRS

SCALES UP WELL CAN BE
FILTERED WITH SQL

• a big table of name/value pairs
• scales up well
• can be filtered with SQL (although awkwardly)
• requires housekeeping
• uses mediumtext to store a boolean

• REQUIRES - HOUSEKEEPING INEFFICIENT FOR SMALL VALUES
• a big table of name/value pairs
• scales up well
• can be filtered with SQL (although awkwardly)
• requires housekeeping
• uses mediumtext to store a boolean

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

• AND - JSON VALUES
• IS A - TWO STEP PROCESS Problem for apps. Requires some mental application logic.

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 "

• Web server isn't necessarily Apache
• We can't use mod_rewrite
• Users don't even stick to one platform
• They might start developing on IIS on Windows and deploy to Apache on Linux

• CHEAP - HOSTING IS CHEAP Some of the big problems are from over-sold cheap hosting. Common to have e.g. PHP sessions enabled, but not working
• temp folder full, not specified, not writable

WINDOWS IS WEIRD

• Server variables can't be relied on
• Permissions are all di " erent
• DIRECTORY_SEPARATOR

MIGRATING

BETWEEN

FILESYSTEMS

• MySQL and mysqldump are di " erent depending on filesystem
• Case sensitivity / preservation is an issue

• NEVER - MIX CASE IN MYSQL TABLE NAMES Stick to lower case

• BE - OPINIONATED
• BUT NOT - DICTATORIAL We said the most di

cult problems are wet ones. Technical problems are hard too.

WYSIWYG

• IS - EVIL We hate WYSIWYG editors. Decided to ship with Textile, Markdown and MarkItUp! Editor.

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.

• with services you can impose your will with software you can only give good defaults but have to allow people to do things you consider bad practice "opinionated software"

EDIT IN PLACE

• IS A - FALSE PROMISE People ask us why we don’t do edit in place. It makes good demo, but we don’t think it scales.

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

• IS - EVERYTHING Getting the end client to use a CMS is a big hurdle for our customers. Clients are confused by things like Wordpress. We designed in features to help. the functionality of software doesn't make it useful on its own - combo of functionality being there ad people being confident to use it. Core di " erence between us and OS projects. They have functionality we work very hard on how it is presented to the user.

EVERY FIELD

• CAN BE - ANNOTATED

help=”Use the teacher’s initials from the timetable.”

perch:help

DRAFTS PREVIEW UNDO We designed features to help give nervous clients confidence

• Drafts
• Preview
• Undo

• BE A - MAGICIAN NOT JUST A DEVELOPER Know your own strengths

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,..

• NOT -

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?