How to list pages and content in Perch CMS

Today, @foamcow on twitter was asking how to list snippets of pages on Perch. So I thought I would have a break and list how I did it – which may not be the best method, but it worked for me.

I had pages with perch content fields, with, for the reason of this example, we’ll call Heading a plain text field, Image (image field) and a Content (textarea).

Initially I though I was stuck, but the forums told me to list the pages I need based on the navigation functions, so in brief, here’s how I did it. Apologies for lack of syntax highlighting etc, will add that later!


< ?php

// Let's get the list of pages according to the navigation first.
// Restrict to the path we need, which is only pages in /projects/
// skip-template means we just get an array of the page data back.
$navigation = perch_pages_navigation(array(
'from-path' => '/projects/',
'levels' => 1,
'skip-template' => true
));

// Now let's loop through the perch content in the project page template
foreach( $navigation as $item ) {

// Add Skip template so we can use the data
$opts = array(
'page' => $item['pagePath'], // This is where we use the data from the nav list to get each page in turn
'skip-template' => true
);

// Now get an array of data for each perch content area in the page template
// All using the same options array we just set using the nav pagePath
$data = perch_content_custom('Heading', $opts);
$desc = perch_content_custom('Content', $opts);
$images = perch_content_custom('Image', $opts);

?>
<article>
<!-- This bit was more complicated for me - print_r your own array to work out what array index you need. -->
<a href="< ?php echo $item['pagePath'];?>">
<img src="/perch/resources/< ?php echo $images[0]['image']['sizes']['w684h386c1']['path']; ?>" alt="" />
</a>

<h2><a href="< ?php echo $item['pagePath'];?>">< ?php echo $data[0]['text']; ?>&lt/a></h2>
<p>< ?php echo $desc[0]['text']; ?> <a href="< ?php echo $item['pagePath'];?>">More</a></p>

</article>

< ?php

} // foreach

?>

And hopefully that should work – but if not it has the basic theory. You can flag items by adding another suppressed field to the project page template and then checking the value in the for loop, which I have done before, although there may be a more efficient way to do that.

An open letter to Middlesbrough Football Club Official Direct Store

After visiting the Middlesbrough Football Club site and MFC Official Direct shop (http://www.mfcofficialdirect.co.uk) today, I was left embarrassed as a Boro fan at the state of both web sites. Below are open letters which I hope representatives of both will see and respond to.

Dear MFC Official Direct

When seeing an advert for the 30% off sale and Boro replica kits for only £15 I was very happy and ran straight over to the store to get myself a replica home kit.

However the experience I had left me shocked, disappointed and embarrassed. Now let me say that I am a Boro fan and a front end developer (so I can understand when things aren’t perfect), but still feel the need to expose the pitfalls of this site in public.

My first issue was when I tried to update my delivery address, having moved jobs and so I couldn’t have the parcel delivered to my old place of work. However it appears I am not allowed to move companies, the company name could not be edited. ANYWHERE. Not on that form, not on my account page, not on mange addresses through my account page, nowhere. The company isn’t even called Gyro International anymore!

Following that annoyance, I thought “Fine, I’ll just add a new address. But then I couldn’t add a company name to go with that, and being in a shared building with many other companies and nowhere to add a company name and few form fields for address I thought I would have it delivered home.

Delivery details on MFC Official Direct Store

I thought that would be fine, but alas no. Following selection of delivery type in step 2 I was thrown to the confirm order page. Step 4. Hold on. That’s missed step 3, and I haven’t entered my payment details yet? But I’m on the last step? Oh well. I guess this really is a good shop! That was confirmed by a nice page telling my my order has been successfully placed! Excellent, I don’t have to pay it seems. Maybe now Mido is back he is funding a shirt giveaway to try and make someone love him!

Alas no, after a second or two I was delivered and Sage Pay (formerly Protx) payment page. Now this possibly isn’t MFC Official Direct’s fault, however it is still part of a flawed process. And anyone that spends £12.7m on Alfonso Alves must have some cash somewhere to invest in a seamless checkout process. Or at least one that allows the checkout page to be on brand, not hideous and at least not be included as step 5 of 4.

The hideous Sage Pay checkout screen.

So after all that and finally getting my payment details in, I notice that Sage Pay have thankfully printed my delivery address so I know its right:

Flat E
London

(They printed my postcode too, but that’s private!)

Now I know the postcode will probably mean that as a delivery address might just make it, and maybe the full address has been stored, but why print only part of the address. Thinking about it, there are quite a few flats in my area so Flat E, Putney might not make it. My address is a required 2 lines before the town and postcode so why not just show me the details so I don’t think you’ve lost half my address along the way. Same goes for invoice address. Just show it all or people (including myself) might not be confident you have managed to pass the correct delivery information and that we may never see our goods, many of which are quite expensive on the MFC Official Direct store.

Anyway, after this traumatic experience it’ll be a while before I use the MFC Official Direct store again, however I also have some gripes with the Middlesbrough Football Club website itself, so this probably isn’t the last you’ll hear from me. Thankfully however, at least the agency that built the site are linked to in the footer, so it can act as a reminder to never, ever recommend Black Magic Digital of Glasgow as a digital agency. They apparently missed out on the user experience chapter of every book they ever picked up.

Yours,

Matt Bee

Boro Fan and Front End Developer

Should designers be able code

This has cropped up lately following Elliot Jay Stocks post (and tweet). So here’s my tuppence.

Should designers be able to code their designs?

No.

But then again it isn’t that cut and dry. I think that there are a very small number of designers that might just be able to get away with it, but they are a minority in the geek world. There’s a reason people like Andy Clarke and Elliot himself are respected so well, because they are skilled and motivated enough to keep on top of design and code. For the majority of us we should specialise in design, front end development (HTML and CSS) or back end development. I also still think there’s a place for pure JavaScript developers (reducing the reliance on jQuery and other frameworks to optimise code).

So should designers know how to code?

Yes.

Learn how designs are laid out, learn how positioning works, learn about floats, browser bugs and the deficiencies of Internet Explorer (and Safari, Chrome, Opera and Firefox for that matter). There should be no excuse for providing designs that are an absolute nightmare to build, but it doesn’t mean you have to be able to build them yourself. If you know the limitations of the technology you can both design to their limitations and think about ways to get round that and make your awesome designs work.

Which brings about an interesting point, the best way to learn HTML and CSS is just to do it, so if you ask the question again, the answer might be different.

Should designers be able to code their designs?

Yes. But don’t let them build the production site.

Why not then, if they can? The intricacies and time spent on testing and debugging is a start, but I also spend a lot of time keeping up to speed on how Google looks at my code, mobile development, I’m still getting to grips with HTML5 and CSS3, I’m work hard on optimising code, and if I had to do all of that and design sites I build I would let myself down in one area. Not to mention I am not a designer, I do code, that is my passion and so I’m sticking to it and not learning design or keeping on top of design to be able to do both.

You could well apply the same principle to the difference between a front end developer and a back end developer, but I’ve got work to do!

BoagWorld

Hoorah! I took a bit of time over Christmas to read and review the book Website Owners Manual by Paul Boag, of BoagWorld podcast and Headscape design agency fame.

My review which I recorded in January made it onto the podcast number 198, and as it was the author presenting the review, it became a lot funnier than I had ever planned!

Transcript:

The website owners manual by Paul Boag, published by Manning Publications

The website owners manual by Paul Boag is targeted to help those who own, run or manage web sites make them more successful. A quiet and humble man Paul has attempted to deliver all the lessons learned through more than 10 years of experience, at all stages of a site lifecycle, into a single resource. The result is a book that will help those responsible for websites be as successful as they can.

Covering topics ranging from selecting the right web agency all the way through to planning for the future, not all content might be appropriate for all website owners, but if the desired audience pick up this book, I don’t think there a single reader that will not learn something and become more successful in their role because of this book.

The book contains succinct well considered advice, which will not overwhelm any reader. I thought there might not be quite enough in depth information, or further resources, provided some sections to really make a difference, like reviewing site analytics. The book could have also better proofed, but this is a matter for the publishers. Not to mention one of the images depicting a developer in a tie.

The website owners manual is divided into standalone chapters that each covers a different stage or process involved in running a website. The 12 chapters cover:

  1. The secret to a successful website
  2. Stress free planning
  3. The perfect team
  4. Differences over design
  5. Creating killer content
  6. User centric design
  7. Ensuring access for all
  8. Taking control
  9. Decoding technobable
  10. Engaging visitors
  11. And finally, Planning for the future

Although not all chapters will be relevant to all website owners, and any experienced website owner will probably have a lot of the advice and recommendations in place, there is still an awful lot to either learn, or be reminded of while running your website.

The topics covered in the book do a good job of providing a feel for the requirements of each stage in the web site process. Some really useful content includes stress free planning, the perfect team, decoding technobabble and becoming number 1 on google.

firstly, Stress free planning, where in the “picture your users” section, Paul explains how you can research properly, prioritize your users and use fictional personas to better understand and relate to your target audience.

The Perfect team does an excellent job of explaining why a brief is so vital, even for small changes. Including an annotated example brief for fictional client “The Joke Factory” to explain why each part of a brief is so important.

Selecting the right people to work on your website might be the most important (and expensive) decision you make in the whole life of your website so it was good to see the steps Assessing proposals, interviewing the short list and evaluating agencies (especially with advice on talking to references).

Decoding technobabble is a problem for all us developers, so despite Paul claiming web developers are going to hate this chapter, I know my clients won’t hate me reading it. Not using simple terms to explain how a website works and introducing concepts like hosting is something I know I frustrate people with, but not for much longer.

Whilst reading the becoming number 1 on google section in the chapter driving traffic I was very pleased to read Paul explains about Black hat search marketing methods and why site owners should steer well clear of these underhand techniques.

In Planning for the future, I can take a lot from concepts such as Microformats, APIs and alternative devices concisely explained direct to my clients.

I really think this book is a must for any person responsible for a website, due to the wide range of topics covered. Although as I said, not all chapters will be relevant to all website owners, there will be more than enough for the book to be a real valuable resource. I like to think of it as a fully fledged consultant sitting on my bookshelf.

There were real moments of enlightenment about how I can help clients really grasp the requirements behind an effective site. I hope this will dramatically improve my client communication using Paul’s thorough but clear explanations of the concepts required for a successful website.

So that’s what I thought about the website owners manual, but its only the tip of the iceberg, and each person that reads the book will take learn something different, so I urge you to buy it and see what it can do for you.

Wireframes

Here at GyroHSR (I had nothing to do with that site, thankfully) we are all a little bit confused over wireframes. Essentially, I think that the main issue lies in what exactly is a wireframe supposed to deliver.

In my opinion I believe a wireframe should simple layout exactly what information should be displayed on a page and define the importance of that information, in relation to the rest of the content.

With this idea in mind, a wireframe does not necessarily have to provide any sort of guide to the actual layout of a page. There isn’t really anything wrong with this for a simple contact page wireframe:

Header elements

Logo – prominent positioning.
Search box – enable users to search whole site.
Navigation – full site navigation.

Main content

Contact form – main content on page, encourage users to use this method of contact.

Secondary content

Postal address – specify preferred correspondence address.
Email address – link to create email for users that prefer this method of contact.
vCard – Download contact details to an address book for future use.

Other content

Company details – registerd company address and registration number.

That will provide the main information required by a wireframe, and producing this format for every page to be developed should meet the designers needs.

However one point above is always missed, producing a wireframe for every page. Without doing this you are not creating an information architecture for a designer to follow, resulting in questioning why wirframes for any pages were created at all.

The same problem applies to wireframes that incorporate some form of layout:

Example wireframe - courtesy of http://totheweb.com

Example wireframe - courtesy of http://totheweb.com

Creating a wireframe for every page becomes even more important with this wireframe style, in my opinion. Creating this type of wireframe for only a small number of pages during the information architecture stage of a web site process results in designers feeling restricted to make all pages following the same layout. Often the content will lend itself to a completely different layout, which means it needs its own wireframe and if not it should be easy to create another wireframe based on what has already been created.

One other thing I often find missing from wireframes are annotations. Visual representation is fine, but if you really want to let a client or designer know what you plan for the page, it needs to be annotated well. The annotations let the wireframe make sense and are vital to communicating the user experience. A poorly annoted wireframe wil result in poorly communicated ideas and will very probably hinder the final user experience.

So that’s what I think about wireframes, feel free to correct me if you think I’m wrong, or to add to this because wireframes are such an important part of the web development process that I think anyone involved in the industry should input into how wireframes can help ease the pressure on project management, information architecture, design and development.