blog

Should you open-source your product?

Wed, 16 May 2012 16:33:50 +1200

Sam Minnée, Chief Executive Officer and co-founder of SilverStripe, has shaped the SilverStripe Suite and is part of its success story as an internationally respected open source CMS. Previously, Sam has posted about SilverStripe 3 beta 2.

As well as being a great way of giving back to the community, open sourcing SilverStripe CMS has worked out well for our company. Does that mean all companies should open source their products? Probably not, but based on our experience, I’m going to suggest a few reasons why you might consider it.

First, a bit of history. Originally, SilverStripe was a closed source product. SilverStripe 1 was never open sourced, and even SilverStripe 2 started life as a closed source product. However, we realised that the core of our business wasn’t selling the CMS, it was using it to build things for our clients that helped make their organisations better. In this light, it made sense to free up the CMS to be more widely used.

For our company, the move was a good one. Soon after open sourcing, we were involved with the 2007 Google Summer of Code programme, which not only gave us the help of a number of students working on the SilverStripe code, it also made more people aware of our fledgling open source project. Enough that, when people were deciding what CMS to use for the 2008 Democratic National Convention website, the name SilverStripe came up. Along with Media 50 and others, we helped build the website, and it was a success. Had we not open sourced, we would have had to spend much more on marketing to get this kind of international recognition.

Open source projects aren’t just hobbies or charity projects, they are a legitimate business strategy. Giving things away can help your business.

How does this work? One important point is that if your power-users are programmers, they’re much more likely to get involved in the ongoing development of your project. As well as getting the benefit of their contributions to code, this makes those power-users much more loyal to your project, because they really have helped create it.

Another related issue is that, for some kinds of products, people expect open source. Outside of the enterprise space, web content management systems fall into this category. Prior to open sourcing, we explored the idea of selling SilverStripe through web shops, as a reseller channel. Although the product was well received, many of these web shops found that they had smaller gigs only had the budget to support an open source project, and by the time a bigger project came along, they had already learned how to use an open source tool and went with that.

Finally, we found that gaining an international audience was much easier with an open source project. It’s not entirely clear why this is, but because you’ve given the product away for free, people are much more supportive.

So, should you open source your product? Three use questions to ask are these:

Is it designed to be tinkered with?

Remember what I said before about having programmers as power-users? A product that is designed to be tinkered with - customised, extended, or modified - is much more likely to be picked up by programmers. Web frameworks are a great example of this. So are content management systems. One of the things that SilverStripe focuses on is providing a programmer-centric toolset of existing the CMS, which means that many of our power-users are naturally going to be programmers.

Is there something related that people will pay for?

This isn’t just an article about open source projects, it’s about open source business models. If there’s not an alternative revenue stream, then you don’t have a business model. (Planning on being bought by Facebook is not a business model any more than purchasing a lottery ticket is an investment strategy.)

Fortunately, there are many options for alternative revenue streams. Customisation or implementation services are a great option if clients get the most value of the product with a bit of tinkering. SilverStripe is a good example of this, and this is our main business. You might also offer training and user support packages. Alternatively, you can offer hosting. A variation on hosting the theme is to have a Software-as-a-Service edition of your product.

Have you got products that aren’t your core business?

If there isn’t an alternative revenue stream that you can tap into, open sourcing a product can still make sense if it isn’t your core business. For example, GitHub and Facebook have both open-sourced various developer tools that are only tangentially related to their day-to-day operations. You can still get the benefits of growing developers communities around these projects, and get the goodwill that comes from giving people something that’s valuable. And, there’s not a lot to lose - if you’re not selling licenses of this code at the moment, you’re not killing a revenue stream by open sourcing.

If none of those apply to your product, perhaps your product is less suited to building an open source business around. However, open source businesses are still relatively new, and every open source business model is an experiment. So, if you have other ideas for building an open source business, don’t let me stop you!

Usability Testing for SS3

Wed, 09 May 2012 13:21:24 +1200

One month ago, Senior Project Manager Julian Meadow (aka J), along with colleagues Paul Clarke and Ryan O'Hara, usability tested SilverStripe 3.0 beta 2 with a number of clients around Wellington, to better understand if the user interface is intuitive or if there are areas that could be improved. I sat down with J to hear more about the long and winding road that is usability testing.

Why did you decide on a usability test for SilverStripe 3.0?

After more staff within SilverStripe became involved with the development of SilverStripe 3.0 and started playing with the early beta releases, we realised there were a number of usability issues that needed to be addressed.

Who do you think should do usability testing? Does every tool and website need to get tested?

I’d encourage anyone building something online that has some form of complexity or workflow to do some usability testing, even if it’s just showing it to a couple of other colleagues and getting their feedback.

What exactly did you test?

We tested the main sections of the back-end interface, the main parts a web administrator would use on a daily basis. We did this by preparing a list of typical tasks, including adding a new user, adding and organising files, creating, editing and publishing a new page, rearranging and deleting pages.

How did you do the testing?

We decided to only test with users that had previous experience in using SilverStripe, and to test at their desk where possible. Two of us from SilverStripe attended each test session, one to run through the tasks with the participant, the other to observe and take notes.

After the testing sessions were completed we (Paul, Ryan and myself, i.e. two designers and a PM with usability experience) reviewed all the results, agreed and grouped our findings and presented these to key staff working on the development of SilverStripe 3.0. During this presentation we made a point of not discussing solutions and instead focussed on agreeing on the main findings i.e. agreeing on areas that needed to be addressed because participants found them confusing or hard to use.

We (again Paul, Ryan and myself, plus Sean for technical input) then worked on developing a number of recommendations. Efforts were focussed on suggestions of how to fix the usability issues raised. We presented these and together agreed on the resolutions and order in which they should be fixed i.e. which ones to fix prior to a full stable release (in beta 3) versus which ones to fix later in version 3.1. Prioritisation was based on a number of factors, including technical complexity and user impact.

How many people did the test and how much time did they have to fulfill the tasks you gave them?

Initially we tested with four individuals. We were prepared to test with more participants if needed (typically up to six participants is adequate), but found after testing with four we had collected enough feedback to work with.

Were the results even throughout the group? Meaning did different people have similar issues or things they liked?

The results followed the 80/20 rule, 80% of the issues were common and reported (reinforced) by all participants, the other 20% of the issues were scattered and more specific.

What were the main findings from the usability test?

Pages section and site tree - participants didn’t understand the site tree’s page tips, found drag’n’drop and multi-selection confusing, struggled to make the connection between multi-selection and the actions dropdown and expected more bulk actions.
Editing and publishing pages - participants found the save/draft/publish button layout confusing, too busy and didn’t provide feedback (a general comment throughout the site). Plus participants were unsure if they were previewing the draft or published site.
Adding and modifying a user - participants found adding and searching users and a number of the related icons confusing. Plus all participants failed to define a group when adding a new user.
Adding and organising files - participants were unsure if the file they had selected was uploaded. Plus they struggled with editing file names and navigating back to the parent folder. Also, when all participants clicked on a folder name in the site-tree/file-tree they expected it to expand to show nested pages/folders.

Were there any surprises for you and the SilverStripe team? Anything that you think would work really great and didn’t or the other way round?

We were surprised how consistently all the test participants tried to use the search user fields to create a new user. A number of factors combined to confuse the participants; bad button labelling and positioning, confusing search boxes and icons. As a result we’re going to rename the “Add New” button to “Add User” and move it from the far right to the left of the screen (following the original designs), plus we’re going to tidy up the user search interface.

Also, none of the participants could log out. One user spent two minutes looking at the interface and finally had to give up. Noone understood that the power icon was the logout button.

Participants were confused by the filters pull-out, most of the time it’s there, but when editing a page it gets replaced by the site-tree.

The biggest finding for us was that all participants felt they weren’t getting enough feedback after completing an action, to confirm it had been done. Examples include participants uploading the same file multiple times because they didn’t get confirmation each time they completed the task and participants were unsure if their draft page had been saved.

On the positive side, all participants liked the new and improved look of the SilverStripe 3 back-end interface.

What are the main tasks coming out of the of the usability test?

We’re looking at a number of ways to address the issues we found. Most changes are small cosmetic things, like changing button labels, using less ambiguous and more familiar icons, and changing positioning so it’s more intuitive with the task. We’re revamping the actions buttons at the bottom of the page editing area, improving labels and tips on the site-tree, improving options to drag’n-drop and multi-select, and a bunch of other stuff to make the user interface more user friendly.

By when will they be completed?

We’re presently resolving the high priority issues (due in the beta 3 release) and will then work on resolving the other outstanding issues, but will most likely hold-off introducing these until release version 3.1

What’s next? Will you do more testing?

Yes, we’re planning to usability test beta 3 after it’s been released, to check the issues we’ve resolved have improved the SilverStripe 3.0 interface and to explore some of the ideas we’re proposing to develop for later releases.

Wellington's May Meetup: Mobile CMS and GSoC explained

Fri, 04 May 2012 00:25:29 +1200

We've published two presentations from this week's Wellington SilverStripe developer community meetup.

Felipe Skroski explained the importance of SilverStripe CMS having a content management interface suited for use on smartphones, showing off wonderful interface designs that we hope shall inspire developers in our community to discuss and build.

Check out resources from the meetup below.

Download design concepts as Adobe Illustrator or PNG files from Github
Presentation Slides
Presentation video recording

My presentation introduced Google Summer of Code. I explained what the programme is, our involvement back in 2007, and all the great stuff we hope shall come this year. Importantly, until 20 May, the students are working in public view of the community to refine their project ideas. We encourage you to have a look through what they intend to work on and please contribute your thoughts so their work is both a wonderful learning experience for them, but also helpful to the needs of the developers and users of SilverStripe CMS.

SilverStripe 2012 GSoC Planning Wiki - review ideas then post to SilverStripe-dev
Presentation Slides
Presentation video

Don't forget that we also have an Open Source Hackfest on Saturday 19 May in Wellington

2012 Google Summer of Code Students and Projects announced

Tue, 24 Apr 2012 12:00:00 +1200

Sigurd Magnusson is one of SilverStripe’s three co-founders. Sig is based in Wellington, New Zealand and works full-time at the SilverStripe headquarters. His efforts are focused on sales, marketing and fostering the open source community.

Google is funding seven talented university students to work on projects to improve SilverStripe CMS. This gives students a highly educative programming experience, and helps further our software immensely. We're very excited, although I'm sure the students are even more so: they only learnt hours ago they've been accepted!

This is all part of the annual Google Summer of Code, whereby over 1200 university students all over the planet are given several months experience working on and contributing to 180 open source projects. It's a highly competitive programme; Google assigned us seven projects to fill and we had four times that number in applications.

The development of all projects will be performed in the open, with the resulting code released under an open source license. Over the coming weeks the project ideas will be refined, with code being written from late May to mid August. Keep an eye out on the github wiki and silverstripe-dev to keep an eye on what's happening and to contribute your own input. We'll post updates periodically to this blog. The seven projects (in alphabetical order of title) are:

1. Content Personalization and Targeting Module

Create a new module to personalise website content for different users. Users might be differentiated by such things as geographic location, in-bound keywords, in-site browsing activity, OS, browser, device, etc. The CMS will support multiple forms of content being written and match content with given users to create a personalised experience.

Student: Yuki Awano (Japan)

Mentored by: Philipp Krenn (Austria)

2. Form and Model Validation

Forms are one of the most important parts of every framework/CMS. The validation layer of SilverStripe isn't very flexible and doesn't handle complex scenarios well. The goal of the project is to allow easy and powerful validation tools on both server and browser side.

Student: Wojtek Szkutnik (Poland)

Mentored by: Matuesz Uzdowski and Sean Harvey (SilverStripe Ltd, New Zealand)

3. Improve Behaviour Testing Framework and Test Suite

SilverStripe has a decent coverage of unit tests, but these typically focus on the technical aspects of the software and don't examine the CMS/framework from the user perspective. The goal of the project is to introduce acceptance tests that simulate user behaviour in the system and check common actions.

Student: Michal Ochman (Poland)

Mentored by: Ingo Schommer (SilverStripe Ltd, Germany)

4. Improve Developer Ergonomics

SilverStripe has a set of features to support developers. However, these features depend on manually adding GET parameters to the URL. The goal of this proposal is to make the tools available at a central, easy to find location in form of a developer toolbar, and to improve a logging mechanism useful for debugging.

Student: Jakob Kristoferitsch (Austria)

Mentored by: Mark Stephens (SilverStripe Ltd, New Zealand)

5. Improve Payment module

Improve API, structure and testing for the existing payment module, and support more payment gateways. The scope is to be further collaborated on by various community members involved in SilverStripe's ecommerce capabilities.

Student: Ryan Dao (Singapore)

Mentored by: Frank Mullenger (New Zealand)

6. Improve silverstripe.org Module and Widgets pages

The functionality of modules and widgets download pages at silverstripe.org is minimal and can be significantly improved. Searching, browsing, and how modules are linked to code repositories will be enhanced.

Student: Vikas Srivastava (India)

Mentored by: Aaron Carlino aka UncleCheese (USA)

7. Module System Refactoring

Currently there's no way to define dependencies of modules, organise them into subfolders or easily submit them to a central repository. Using the newly popular composer/packagist pair, allow module authors to define dependency metadata for a module inside a JSON file and enable versioning to be inferred from source control. This will simplify the installation and management of modules.

Student: Andrew Short (Australia)

Mentored by: Marcus Nyeholt (SilverStripe Pty, Australia)

SilverStripe 3 Beta 2

Fri, 20 Apr 2012 15:57:45 +1200

SilverStripe is proud to announce the release of beta 2 of the SilverStripe Framework 3.0 and SilverStripe CMS 3.0.

What's new?

As you might expect, beta 2 builds on beta 1. As well as a host of bugfixes, here are a few of the new features:

A "list view" for pages. This has been a much requested feature and will be particularly useful to those who manage blogs and other sites with content that doesn't fit the nicely into a tree.
Image insertion and media management have been improved, including an "insert from the web" option.
The usability of the tree view when editing content has been improved.
A new default theme, Simple, that responsively handles narrow (e.g. smartphone) and wide (e.g. desktop) layouts. (Demo.)
In 3.0, SilverStripe now works with PHP 5.3+ in order to take advantage of all the PHP 5.3 features.

If you want all the details, you can check out the full changelog.

What's next?

Next up, we are planning a beta 3 release. A few of the things you can expect:

Now that we're 5.3+ only, we can make use of namespaces. We will move the SilverStripe classes into PHP namespaces to reduce the chance of conflicting with other PHP packages you may want to incorporate into your project.
We've been running user testing, and we will take feedback from that and make more usability enhancements.
There will be more work to improve performance.

As always, we will be continuing the discussion on the silverstripe-dev Google Group and tracking our work in progress on open.silverstripe.org.

Want to get involved?

If you'd like to help us get from beta2 to stable, here's what you can do:

Download SilverStripe 3.0.0-beta2
Install it, or upgrade an existing site, and try to break things
Report any issues you find on open.silverstripe.org.

Thanks to everyone who has been involved with the development of 3.0 so far, we are getting very close!

The Opportunity of Responsive Design

Wed, 18 Apr 2012 15:41:28 +1200

Paul Rogers works as a Senior Online Marketing Strategist for GPMD, a London-based web agency who are one of two UK SilverStripe partners. GPMD also organise and run the UK SilverStripe meetup event.

In February 2012, my colleagues Matt Bailey and Sveta Coward entered their theme designs (Sunrise & Tangerine) for the SilverStripe theme contest. Both themes were designed and built with responsive functionality, meaning they respond to different devices to provide a more user-friendly browsing experience.

The amount of people using their mobile phone to browse the web is increasing every day, with nearly 30% of all internet usage now coming from mobile devices.

More interesting mobile internet statistics:

On average, four Ferraris are sold every month via mobile phones
52% of UK mobile phone users have a smartphone
28% of UK mobile phone users have purchased something on their phone
50% of flowers ordered online on Mother’s Day were from mobile devices
The number of Google searches from smartphones doubles every two months
In the UK, smartphone sales overtook PC sales last year
Nearly 20% of traffic in the travel industry is mobile (nearly doubled in the last 12 months)

These statistics are from a mobile marketing event I attended last month. There are more statistics in this blog post.

An investigation into the growth of mobile traffic

I carried out an investigation using the Google Analytics data of some of our clients, the results can be seen below.

The Investigation

Looked at 20 websites (combination of ecommerce & non-ecommerce)
The websites were split across various different industries
Data taken for March 2011 vs March 2012
The mobile data includes iPad users

The Results

Two websites saw an increase of over 500% in the percentage of mobile of their total traffic
The average increase in the percentage of mobile traffic was 225%
All of the websites saw an increase of over 100% in the percentage of mobile traffic
Our fashion clients get the highest percentage of mobile traffic
Mobile traffic for one retail client has increased organically by nearly 2000%
Traffic for our finance clients is around 22%
The percentage of mobile traffic for our fashion clients is just under 20% higher than our finance clients
Mobile makes up an average of 14.75% of traffic on average

This data is only based on traffic from websites we manage.

As you can see from these statistics, mobile internet usage is growing at an unbelievable rate, which is why responsive design represents such a strong proposition for businesses.

In 2010, Google became a mobile-first company - meaning they design and develop all of their tools and websites for mobile devices before designing for desktop computers. We’re now applying this principle to all SilverStripe and Magento websites that we build, delivering responsive websites that are scalable.

Understanding the opportunity that mobile represents for your business

In some cases, adapting your website to be more mobile-friendly might not be a cost-effective option, you can find out by doing the following:

Review your traffic in Google Analytics

If a lot of your visitors are coming from mobile devices, then a mobile website or responsive design could prove to be a big opportunity.

Check the devices your visitors are using

Once you’ve identified the mobile devices that your visitors are using, you can then test to see how your website renders on the given device.

If you would like to read more about mobile marketing and websites, I’ve written the following posts on the GPMD blog:

Why you should be thinking about mobile
Apps vs Mobile Websites

How Simple came to life

Wed, 11 Apr 2012 12:27:12 +1200

Sara Tušar Suhadolc is the winner of the SS3 default theme contest. Sara works as a web-designer/front-end developer at Slovenian digital agency Innovatif. We asked her to share the story of how her theme Simple came to life.

Over a year ago, we decided to ditch our own CMS and switch to SilverStripe. Since then, we’ve published numerous websites and learned a ton along the way. When we heard about the contest we saw it as a superb opportunity to finally give something back to the community. And so it begun..

I started working on a design two weeks before the deadline. The aim was to create a high-quality responsive theme that could easily be customized. There were a few versions of it, but in the end, I decided to abandon all the unnecessary elements, kitchy details and make it as simple as possible. I was juggling between three different typefaces for the headings and went for the Cambo Regular in the end, which among other qualities has a lovely ampersand (I’m a sucker for those!).

This has been an extremely valuable experience and I would like to thank Innovatif for being so supportive, the SilverStripe team for organizing the event and being there for me when I needed them, and Ethan Dunham for running the amazing free font conversion service FontSquirrel!

At the moment, we are polishing some last CSS details, so that even all those generated forms will look perfect for the official release. Can’t wait to see it live and kicking!

You can take a sneak peak of Simple in action here.

Duck Programming

Wed, 04 Apr 2012 15:21:05 +1200

When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.

One thing that a few people have asked about is whether SilverStripe has modules similar to Drupal’s Content Construction Kit (CCK) and Views modules.

If you haven’t heard of CCK or Views, the one line summary is this:

CCK lets CMS users define new content types
Views lets CMS users build new templates based on those new content types

(Disclaimer: I’m not a Drupal expert!)

The short answer is that we deliberately avoided building features like these into SilverStripe. We have taken a different approach when creating SilverStripe, and I’d like to explain why.

In essence, the appeal of these systems usually seems to be to avoid having to 'do more programming' in order to add new features to the site.

Reg Braithwaite coined an apt expression for this: Duck Programming (a play on the term Duck Typing). He defines Duck Programming as “any configuration that defines or controls mission-critical behaviour of a software system that is thought to be ‘not programming’ because it doesn’t appear to involve programmers, programming languages, or programming tools.”

The point is that putting a different face on programming doesn’t really stop it from being programming in practice. We had actually tried this approach in an earlier product (the never-open-sourced SilverStripe 1). What we found is that, although some simple systems can be set up with a model like that, most of the time people hit the edge of what can be provided.

Software developers have spent decades coming up with effective ways of describing application functionality that are both flexible and concise. The result of that effort are modern programming languages such as PHP and Ruby, and modern frameworks such as SilverStripe and Rails.

Furthermore, there are all kinds of things beyond the code that software developers have adopted to manage the risks involved; things like version control, automated testing, environment management, and deployment pipelines. Most duck programming systems ignore all of this.

Because of this, we have deliberately avoided building duck programming features into SilverStripe. However, that’s not to say we never will. If we were to build and maintain such a system, we’d want to see it support these things:

Any custom functionality built using developer APIs built would need to be able to be extended by the duck programming system.
Any custom functionality built in the duck programming system would need to be able to to be extended by using developer APIs.
There would need to be a graceful hand-off between the base functionality that can be duck programmed and the extensions that are only possible with the developer API.
All changes made by the duck programming system would be put through the same version control, test automation, and environment management controls as the rest of the code.

All of this is achievable, but it wouldn’t be a trivial progress, and we have been putting our development efforts into other areas, because frankly, we don’t see these features as a panacea.

One of the appealing things about duck programming systems - a commonly quoted reason for wanting this feature - is that you don't need programmers involved to keep growing the site. Often the word “programmers” is accompanied by a grimace, and a subsequent expansion on how frustrating developers are to work with. This saddens me more than it surprises. We believe keeping developers involved in the ongoing maintenance of an application is a good thing.

If you accept our assertion that programming code is the best way to reliably describe the functionality of an application, then perhaps you will agree that it is more useful to find better ways for the team to work with developers, rather than opting for a band-aid solution like duck programming.

To borrow the phrase of another open-source developer, SilverStripe is opinionated software: it is a CMS and Framework optimised for sites where business owners, developers, and designers work together constructively, rather than trying to avoid each other. This might not be precisely what you are looking for, and that’s fine too. It is a bad idea to try and make a product that is everything to everyone, and this is the niche we have chosen for SilverStripe.

But it begs the question, doesn't a collaborative approach to web development sound like a better way?

SCSS, Compass and SilverStripe 3.0

Tue, 27 Mar 2012 21:56:45 +1300

Will is a senior developer at DNA Design, Wellington, New Zealand. He has been a contributor to SilverStripe since 2007, maintains several modules and is a well known face around the IRC and Forums as willr.

Over one year ago now, a group of us got together and started thinking about how we wanted to implement Felipe's awesome new UI for SS3.0, and how should SilverStripe go about turning the pretty pixels into reality. The design itself was a product of some fresh thinking from the UX front, so it felt right that we take the same care in designing the front-end architecture.

The CSS behind SilverStripe 2.X was the result of over six years of battle-hardened and tormented stylesheets. Cluttered over the years with more and more styles, hacks, odd classes and work arounds for undisclosed edge cases that arose over the long years as SilverStripe grew and grew. While at the same time, the entire landscape of front end development was evolving, and it has now morphed into a totally different beast to the one that was around when SilverStripe 2 was first conceived (though IE7 is still around!).

As everyones putting a huge amount of effort into developing, testing and bugfixing the new CMS for 3.0, it makes sense for us to use a tool that could take some of the pain out of quickly implementing the modern, dynamic CSS that we need while giving us a solid base to last another six years.

To help us with this, we turned to a stylesheet language called Sass and a Ruby-based tool called Compass. At this point I can hear the sighs and murmurs about how you don't want to be forced to use Ruby to develop with SilverStripe, but truly, as the uber cool engineer you are, it's good to get out once in a while. We shouldn't be scared of new things, go meet them, relax, and you'll be fine. Plus, we've got an easy module to help run Compass, and you only need Ruby and Compass installed if you want to customise or alter the core CMS and framework styles. If you want to include plain old CSS in 3.0 you still have the freedom to do so, but personally I love some of the features Compass has to make my life easier.

I should also mention at at this point, I'm still experimenting with what's possible in our Compass - SilverStripe integration, as well as some of the implementation details of our CSS, so if you have thoughts or opinions please post on the dev mailing list.

SASS / SCSS?

Sass (Syntactically Awesome StyleSheets) is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance which is compiled into standard CSS. It comes in two syntax flavours; SASS and SCSS. Each have their own ins and outs to the syntax but in 3.0 we've gone with SCSS, which has a similar style to original CSS.

Compass?

As the Compass site puts it, Compass is an open source CSS Authoring Framework. I mentioned in the previous paragraph that SASS is compiled into CSS; Compass handles this compilation for us and provides a further set of tools on top of that. Things like reusable common patterns (such as clearfixes), functions for operations and mixins for CSS 3.0 properties. These tools, on top of the language features of SASS/SCSS, all help decrease the SLOC of CSS that we'd need to maintain in the core.

SCSS + Compass + SilverStripe 3.0 =

Since this is only a short introduction, I recommend you pursue the Compass and Sass websites for more extensive information on each, but I want to highlight a couple things we're using.

SCSS Variables

One thing I love about the SilverStripe community is that I'm surrounded by amazing fellow web developers choosing to invest time and effort into building applications and websites for their clients on SilverStripe. I was once asked by a developer if they could re-brand SilverStripe; not only is this allowed, we're trying to make it even easier in 3.0. In 2.4 you could easily change the name and logo but any CSS changes had to be hacked on top. Now, by building the back-end interface out of SCSS variables, we can open a range of possibilities for branding.

We're still working out the kinks as to how this is going to work, but you can see a quick example of an admin 'theme' on github. We use a lot of the Compass helpers such as darken() and lighten() as well as the linear gradient mixin in Compass to change the whole interface based on that short list of variables.

Our goal is that module authors and site developers will be able to easily create their own SCSS variables for the back-end and replace existing ones in their own themes. In theory, allowing for a branded CMS experience to be developed easily and quickly.

sprite-map();

This clever little helper comes out of Compass and helps build sprite maps dynamically. A sprite map is a single image that includes a collection of smaller images. The purpose is to reduce the number of HTTP Requests as rather than loading 12 images, the browser loads the one map. When the first designs came out, SS3.0 included a magnitude of icons that we knew needed to be accounted for, but at the time didn't have a complete list, or any actual icon libraries, so by using sprite-map() we could include the individual icons in a folder and let compass build the sprite for us. As designers added more icons, they could just put the single icon files into the folder and allow compass to do all the hard work.

See how we do icon sprites

Nested Selectors

As part of our goal to write cleaner, more encapsulated code for the back-end, a significant portion of the back-end is written in nested selectors which reduces repetition and encourages intelligent thinking about where selectors should be placed.

Conclusion

The current implementation of the new back-end CSS is only the start of our process of building a new solid, extendable core back-end CSS architecture. While the 3.0 UI and UX is still being teased out, we as developers have a long journey of refactoring and constant refinement ahead. Help SilverStripe by staying vigilant and we can all contribute to ensuring SilverStripe has clean, extensible and maintainable SCSS for many years to come.

Upgrading to SilverStripe 3.0

Thu, 22 Mar 2012 12:29:43 +1300

Simon is a developer at PocketRent, a SaaS using SilverStripe. I'm currently working towards completing my Honours degree in Computer Science and Maths. I'm simon_w on both Twitter and the #silverstripe IRC channel.

Since beginning to use SilverStripe back when 2.2 was about to be released to the world, the most complex upgrade path was between 2.3 and 2.4, when, rather than simple replacing the Sapphire and CMS folders with the newer version (as well as updating any modules, of course), the jsparty folder had to be deleted.

Four and a half years after starting with SilverStripe, the release that is looking to have the most involved upgrade path is being prepared in SilverStripe 3.0. To help ensure the upgrade process goes as smoothly as possible when 3.0 is released in its full glory, beta 1 is available to allow people to test drive the new Framework and CMS, as well as testing the upgrade process.

Due to the magnitude of changes to both the CMS and underlying Framework in 3.0, updating anything but the most basic of sites to the beta version is likely to require some fiddling. Always run the upgrade in a testing environment and always backup your database and files before running the upgrade.

You can read about many of the benefits of upgrading to the 3.0 beta; the new Framework, grid field and the new ORM in blog posts, the dev channel and in the documentation.

Should I upgrade to beta?

These new features are definitely worth using, but many are wondering whether to upgrade to beta. The answer to that question depends on how comfortable you (and your clients) are using beta software.

Due to the changes in the CMS, any module that adds pages (like the blog module), adds functionality to every page (like googlesitemaps) or has its own interface in the CMS (like userforms) will not work until they're updated. Some modules will continue to work fine without any changes required, though if your site relies on many modules that haven't been upgraded or can't be easily replaced (e.g. DataObjectManager can be replaced by GridField, and Uploadify can be replaced by the new UploadField), then you shouldn't upgrade to 3.0.

On the other hand, if you want to make the modules ready for 3.0, by all means upgrade and submit patches to the author of the module.

If you have a large, existing code base you need to decide if it's worth upgrading to 3.0 at all. For some sites, this will take a reasonable amount of time, especially if it relies on some of the more advanced features of SilverStripe. If you do decide to upgrade such a code base, I suggest waiting until the stable release of 3.0.0, just so a change between now and the stable release doesn't break your entire site again.

However, upgrading a branch of your site to 3.0, and then keeping up with changes as they happen, will provide a lot of useful testing of 3.0 and should, hopefully, discover lots of minor bugs or things that just don't seem to work logically.

If your code base is simple enough, it is also worth considering if it'll be easy to just rewrite your code to take advantage of the new 3.0 features rather than upgrade. As the database structure remains the same, just create your classes with the same names, database fields and relationships, then write your functions again.

Running the upgrade

Running the upgrade is rather similar to upgrades in the past. First, backup your database and code. Now simply replace the Sapphire and CMS folder with the newer versions. If you are planning on contributing fixes back, I recommend using the master branch from the git repositories. Otherwise, use the folders in the beta1 tar ball. Then run/dev/build. If all goes well, your site should now be using 3.0.

This process will be enough in only a very small number of cases. The upgrade documentation lists some things that have changed that you may need to update on your site. Of particular interest are the changes to form fields' constructors, features that have been extracted out into modules and the deprecated/removed classes.

If you do decide to upgrade to the 3.0 beta, core developers want to hear how it went! We invite you to record what you had to do, and let them know.

Predicting the Future of Mobile Development at SXSWI

Mon, 19 Mar 2012 16:37:15 +1300

Guest blogger Josette Rigsby has over 15 years experience in leading technology teams and delivering solutions. She has a special interest in enterprise architecture and emerging technology. Josette attended the SXSW in Austin last week and is here to give us the low down.

South by Southwest Interactive (SxSWi), the annual pilgrimage of thousands upon thousands of techies to Austin, TX to learn, pitch start-ups, commune with their peers and (of course) party, has concluded. This year’s conference was held March 9 to Match 13. SxSWi attracted more than 20,000 attendees and featured over 1,000 panels. Each day every conference room, event hall and corridor was filled with discussions of the latest trends and what might be coming next. Given the gadget loving audience, it shouldn’t be too shocking that mobile technology was one of the most common themes in many of these conversations.

Mobile technology adoption has grown at an astounding pace. Mobile Internet usage has doubled every year since 2009, and analysts project mobile browsing will surpass traditional desktop Internet use by 2015. Our desire to be constantly connected to the digital universe has resulted in over 5.9 billion mobile subscriptions. That’s around 87% of the global population and a huge market for all types of mobile applications and content. SxSWi sessions like: Why Mobile Apps Must Die, Mobilizing Web Sites: Strategies for Quick Mobile Web Implementation, Best Practices: Native + Web Hybrid Mobile Apps and Demystifying the Future of Web and Apps, explored the challenges of creating engaging mobile experiences from almost every imaginable angle. A sprinkling of attendees and I rose early on the last day of the conference to attend the “The Right Tool for the Job: Native or Mobile Web?” panel, which featured

Buzz Andersen and Jacob Bijani of Tumblr
Majd Taby of Facebook
Matthew Delaney of WebKit
Tom Dale of Ember.js

debating a decision that many developers and organizations face – build a mobile optimized website or create a native application. Clearly the mobile market is going to continue to grow, so what’s the best way to support the seemingly infinite device choices and provide the best user experience? It’s a decision that has become even less clear with the emergence of technologies like HTML5 and JavaScript frameworks that have reduced the gap between web and native user experiences.

The Right Tool for the Job: Native or Mobile Web panel

The panel began with a brief history of how creating modern software has evolved from using early low-level, machine specific languages to highly abstracted web-based development and finally to the age of the app. Native development has long been “the” way to create rich, highly interactive mobile applications. However, developing native apps comes with a number of challenges – no standards, difficult to deliver dynamic content, a constant stream of new devices and a lack of cross device/platform compatibility. These factors can result in long test and development cycles, high levels of complexity and significant expense, but native development is not the only choice for delivering mobile applications. Approaches from CSS-based responsive design and locally rendered HTML (Flipboard) to HTML5-based mobile websites (Financial Times) and native/web hybrids (Apple App Store), now offer capabilities that rival native solutions. It is important for developers and designers to understand the nuances of each option to make the best choice for their project.

Google iOS web app

Facebook hybrid native/web app

Web, Native or Little of Each

The popularity of Apple and Google Android app stores has made mobile delivery almost synonymous with native development. Locally installed applications developed in Objective-C (iOS), Java (Android and Blackberry) and .Net (Windows mobile) offer:

Fast performance
Tight integration with operating system and device
Native user interface components that conform closely with the device
App store distribution
Several easy to implement monetization options
Ability to function without an Internet connection

However, native development is the most expensive and time-consuming option for mobile applications - especially when multiple platforms must be supported because the application must be customized for each supported platform (and often platform version). The challenges of native development have led many developers to embrace alternatives.

Although many developers have traditionally viewed web applications as poor performing substitutes for native applications, that’s no longer the case. Mobile web development has advanced; it’s now possible to create sophisticated user experiences using HTML, CSS and JavaScript. Developers can even manage the content using content management tools like SilverStripe. Web apps are often:

Faster to develop
Easier and cheaper to staff with development resources
Excel at displaying and delivering dynamic content without deploying app store updates

Web apps are also getting faster as browsers begin to support technologies like WebGL. Panelist cautioned against attempting to create web apps that simulate native features. This often results in lots of overhead, poor performance and a potentially negative user experience.

Yet, web applications aren’t the right tool for every scenario. For example, high performance games are likely a better fit for native mobile development since they often require more than the limited amount of application cache and local storage allocated for each web application on platforms like iOS. In addition, native apps may gain access to device capabilities before web applications; for example, Apple exposed iCloud APIs in advance to iOS developers allowing them to integrate the technology in advance of other developers. These issues will become even more important as hardware-based payment technologies like NFC becomes more prevalent. There can also be variance in the features supported by mobile browsers. The problems aren’t as significant as cross-platform compatibility issues, but all the panelists noted that more standards are needed for mobile browsers. In the interim, tools like rng.io, developed by Facebook and Bocoup, can help developers instantly understand what capabilities are available in a specific mobile browser. Rng.io shows feature compatibility visually using rings (hence the name) and includes a drill down that details exactly which tests a browser passed or failed.

Rng.io report

Pure mobile and pure web aren’t the only choices; you can also mix the approaches and create hybrid applications. Native apps are really about using the best tool for the job, and many recognizable brands like Apple (app store), Netflix and LinkedIn use this approach. Most hybrid applications wrap web content in a native shell and call device functions as needed making hybrid apps almost indistinguishable from a pure native application. Hybrid apps can be easier and faster to build than fully native apps and they are easier to update since only the changes that impact native code require redeployment to the app store.

Choosing which approach is best is almost always a grey area. You should try to determine:

Who is the target audience?
What devices is your target audience likely to use to access the site?
What are the key goals of the application (e.g. revenue generation, traffic etc)?
What native capabilities are required or there other implementation options?
Are you building or buying?

Once you are able to answer the questions, determining the right platform should be easier.

What’s Next in Mobile Development

After discussing the various development options for targeting mobile devices, the panel explored the future. What’s the best approach going forward? The answer – nobody knows. While Jacob Bijani of Tumblr and Tom Dale of Ember.js felt a hybrid approach could offer the benefits of native and web development and let implementation progress quickly, Maijd Taby of Facebook said,

Hybrid development is a road frocked with danger. There are so many ways that the native and web client can get out of synch.

There isn’t a simple answer. Currently there is no technology convergence. The mobile market is growing and moving too fast for anyone to really know where mobile development or devices are going. Device, platform and browser technology will continue to change each year making it almost impossible to develop a strategy that’s future proof beyond a few. The best developers can do is ensure their applications have good separation of concerns. Loose coupling will make it easier to perform the inevitable changes that will be required when mobile technology evolves. This may not be a popular conclusion, but it is reality.

SilverStripe 3 Beta 1 Release

Tue, 13 Mar 2012 13:46:36 +1300

SilverStripe is proud to announce the immediate release of beta 1 of the SilverStripe Framework 3.0 and SilverStripe CMS 3.0.

For several years the SilverStripe 2.X line has provided a flexible open source CMS platform which has proven itself as a strong, competitive, feature rich and user focused option for content driven websites.

It has also proven itself as a valuable platform for developing websites with broader scope than traditional content driven sites in SilverStripe Ltd’s commercial website development endeavours

However, technology and user expectation moves on, as does what we strive to attain with this technology. With this in mind, SilverStripe has spent the past several months working on SilverStripe 3.0. SilverStripe 3.0 is a full re-examination and refresh of the SilverStripe CMS platform, with the primary goals being:

Separate Framework from CMS, so that Framework is usable on its own, making it a fully fledged stand-alone entity rather than primarily a support framework for the CMS product as in the 2.X line.
Refresh the CMS administrative interface with a more modern design and user experience, and a more technically solid javascript underpinning.
Replace or improve developer APIs that have reached the limit of their expandability in their current form for backwards compatibility reasons, or are considered difficult to maintain.

With this Beta 1 release we have now completed the majority of this underlying refactoring. We now believe we have a feature complete and API stable platform to build from. Though not considered production-grade, there remains several known issues, and more are sure to be found through further testing. This release is now ready for developers (both of websites and modules) to begin integrating with their existing codebases.

Therefore we invite developers, community members and organisations currently using, or considering using, the SilverStripe platform to try out this release. In specific, we see this release as useful for people who would like to:

Test upgrades of existing sites to the SilverStripe 3 system
Upgrade existing modules to be compatible with SilverStripe 3, so that they can be released concurrently with SilverStripe 3.0 Stable
Test and raise bugs, to help improve the quality of the final stable release
Begin developing websites that have a scheduled release mid-this-year or later
Just generally check out the changes in the CMS administrative interface

However, there are some things that you should be aware of when trying out this beta version.

There are known issues of medium and higher severity remaining in the code base. This could include bugs that cause data loss, although we’re not aware of any. You should back up your assets & database before upgrade and regularly during use
Although we have similar goals for eventual browser support in the SilverStripe 3.0 admin interface as we do in SilverStripe 2.4 (with the notable removal of IE6 support), there are currently known issues in older browsers that do not support newer HTML 5 features which affect both performance and general operation (details).

Because of these issues, we do not consider this beta release suitable for non-technical public use or developing websites that need to go live earlier than mid-this-year.

For a detailed list of all the features and changes in this release, please check the change log and our upgrading guide. For a list of known issues, or to raise new ones, you can view the current bug report on our trac.

We hope you enjoy working with this release, and look forward to community feedback. See you all at beta 2!

Google Summer of Code 2012 Project Ideas

Fri, 09 Mar 2012 15:15:02 +1300

UPDATE: SilverStripe has been accepted. Students interested should read our project ideas below, and begin discussing with us about their project ideas ahead of the 6 April student application deadline. (Read why we are asking students to make their project submissions public.)

In 2012, with the release of SilverStripe 3.0, we are applying to be part of Google Summer of Code, just as we did back in 2007 when we released SilverStripe v2.0. Should we be successful in our application, this page provides information for students on projects they can work with us on.

What is Google Summer of Code?

Google Summer of Code (GSOC) is an annual, global, program where university students work on open source projects. Students write code, receive a stipend, learn a lot, and have lots of fun. Open source projects like SilverStripe get wonderful new features (see the impressive results from our previous experience), and overall, interest in programming, the web, open source, are boosted. Read more at the GSOC 2012 website.

I love it. How can I join up?

If you're a university student, there's a detailed GSOC FAQ to read over. By March 17, Google will announce whether SilverStripe is part of this year's program and students can begin discussing ideas for projects with us. We have listed some project ideas below but are also very open to great ideas from students. Applications must be in by April 6 (19:00 UTC).

Project ideas

We used a public wiki to enable people to come up project ideas publicly. Full details for each project are found there. A summary of the ideas we started off with are:

Accessibility improvements for the CMS
Improve silverstripe.org module and widgets pages
Help port SilverStripe 2.x modules to SilverStripe 3
Improve Facebook Integration
Developer Toolbar and Improved Framework Logging
Improve Behaviour Testing Framework and Test Suite
Improve installation and upgrade process
Create Content Personalisation and Targeting module
Improve geospatial capabilities
Improve Dynamic Templates module

Students are encouraged to discuss with us how to refine these or create new project ideas between March 17 and April 6. (We'll publish a blog post on how to work with us.)

Preliminary Mentors

A mixture of SilverStripe staff and community members will act as mentors for the students:

Ingo Schommer, Development Manager, SilverStripe.

Mark Stephens, Development Manager, SilverStripe.

Rainer Spittel, Head of Development, SilverStripe.

Hamish Friendlander (Backup mentor), Chief Technical Officer, SilverStripe.

Nivanka Fonseka, Software Engineer, SilverStripe community member.

Frank Mullenger, Web developer, SilverStripe community member.

For further information on SilverStripe's application for Google Summer of Code, please feel free to contact me at sigurd@silverstripe.com.

And the winner of the Theme Contest is..

Mon, 05 Mar 2012 17:59:08 +1300

It was very close, but the judges have agreed on a winner for the SilverStripe 3 Theme Contest. The trophy of becoming the default theme for SilverStripe 3, and winner of the Samsung Galaxy Tablet is:

Sara Tušar (Innovatif) with ‘Simple’

For such a simple theme, it’s really powerful and very well implemented. The typography is lovely, the whitespace is perfect. Fresh, open, spacious, clear, easy to read and navigate. Feels great. Well done. It’s almost devastatingly clear and simple. The triumph of usable work is that you can't even see how you could get confused. -Tom Coates

I was “shocked” with this design from the first time I saw it. Clean, crisp, simple and nice! Awesome usability concepts. Again, it's simplicity and slick look makes it the best of this category (usabilty) too. -Eduardo Cesario

Nice and simple! It’s easy to imagine any site using it. -Felipe Skorski

Here are the finalists, in order of placement:

1. Sara Tušar with "Simple" (Innovatif)
2. Hannes Wizany & Zauberfisch with ‘Simpli’
3. Matt Bailey (GPMD) with ‘Sunrise’
4. Anselm Christophersen with ‘Cloudy’
5. Simeon Stamenov with ‘SilverBride’

A big congratulations to you all. You’ve done an amazing job!

This was a design contest and not a coding contest, but still, the quality of the code counted towards 30% of the final result. A big ‘Thank you’ to Jared Fullerton from Bluehousegroup, who took the time to check and comment on all the code from your entries. Here are the ratings, in terms of quality of code:

1. Hannes Wizany & Zauberfisch with ‘Simpli’
2. Anselm Christophersen with ‘Cloudy’
3. Matt Bailey (GPMD) with ‘Sunrise’
4. Sara Tušar (Innovatif)
5. Simeon Stamenov with ‘SilverBride’

As the icing on the cake, I asked the judges to pick an extra theme that was not among the top five rated themes, and rate as the ‘Expert’s Choice’. Amazingly enough, three out of five judges independently from each other picked Tangerine out of the remaining fifteen themes.

Congratulations to Svetlana Coward from GPMD, she created Tangerine. There is no material prize for you, but you will receive a badge for your website to promote your work. (More about the winner and finalist prizes in a later post).

The competition was really hard, so don’t be disappointed if you didn’t quite make it. As I said before; we are all winners with this Theme Contest. The community now has fresh, new themes that will make evangelism for the CMS so much easier.

If you missed checking out the entries, here are the top 5 themes up in the gallery.

Our aim is to work hard and see if we can get ‘Simple’ into beta 3.0. We will also come up with ideas about how to bundle all the other themes from the contest to make them available for download. I will keep you updated on the status of that.

Getting stuff done with SilverStripe

Wed, 29 Feb 2012 10:06:19 +1300

Ramon Kupper is the founder and managing director of pixeltricks GmbH, the german company behind the eCommerce module SilverCart. He has a degree in computer science and is passionate about eCommerce and content management. His table soccer gatling technique is vicious and fortunately nobody has been hurt so far.

When Borland released Delphi in 1995, they were among the first to adapt the new paradigm of Rapid Application Development (RAD). I was still an apprentice in my second year, but I recall that the general opinion was that - with the given productivity boost and the visual programming style - very soon programmers would be obsolete. They were all wrong. So wrong.

It took about another 10 years until frameworks for PHP began to gain momentum and some of them are still far from enabling real rapid application development.

When dealing with PHP frameworks, a lot of buzzwords float around and there are also a lot of attempts to compare the features in order to declare a winning framework. As if you could choose the best meal by just comparing the ingredients. Don‘t get me wrong - of course the quality of the ingredients does play an important role. But if you gave three famous chefs the exact same fixings, I would eat a banana sideways if they all came up with identical dishes. Even though modern frameworks all have OOP, ORM, MVC, DRY, KISS and many more cryptic acronyms on their feature list, the end result is quite different.

Instead of comparing features we should ask: will it help me to get stuff done, or will it just drain my energy slowly until I have too much invested to quit?

I think that getting stuff done is one of the things that matters most when you want to develop/create/achieve something meaningful. At the end of the day, only results matter.

A pretty impressive example of how much you can get done with SilverStripe is our eCommerce module SilverCart.

You have never heard about SilverCart? No problem, here is a quick rundown: We began to work on SilverCart in August 2010, when we sat together and planned the business logic with a UML diagram. Roland then began to convert our ideas to code with the knowledge of SilverStripe he had gained from Ingo's book. About three months later, we had a very basic but working eCommerce module for SilverStripe and in January 2011 we developed our first projects with it. Version 0.9 was then officially released under the LGPL license in March 2011.

Currently we are working on version 1.3 and it is growing permanently. Today, SilverCart consists of

232 classes
1062 methods
47538 lines of code
184 files

We have about 15 modules that enhance the basic functionality of SilverCart - modules for payment, marketing and invoicing. We even created a module-wizard, which puts together a custom download package with the modules you choose for your SilverCart installation and even allows automated installation. You can see it in action here.

Thanks to the underlying SilverStripe framework, we are more motivated with each module, each line of code we write, each line of documentation.

But what exactly are the features that we value most? What is really speeding up the development of SilverCart?

Data Model Management

It‘s so easy to add a new attribute or a new relation to an object, it almost feels like cheating. Having a customized data model that exactly matches the needs of the product range makes our clients lives so much easier. Inexperienced developers don't have to worry about SQL syntax and can query the database in a more intuitive fashion. Getting new developers up to speed quickly is a huge asset.

Scaffolding

Having the customized data model ready to run in the admin panel saves tons of work. Usually, a client comes up with a new attribute right before the deadline. Thanks to the proven scaffolding mechanisms, things like this can be done in almost no time and save heaps of time on a regular basis. Every now and then we are reaching the limits of the scaffolding mechanisms, but there is always the possibility to find a way around.

Architecture & update mechanisms

Using the almighty decorator pattern - a structural design pattern - updating even complex modules is as easy as falling off a log. Even heavy modifications to the core can be updated easily. We are able to keep all our SilverCart installations up-to-date without having to burn the midnight oil.

Consistency of database definition and business logic

Being able to rely on the consistency of database and business logic is a huge asset. Especially when you are moving projects from staging to production or installing new modules the famous „dev/build“ makes your life so much easier. If you have ever had a project where database definition and business logic were not in sync, you don‘t want to miss this feature.

Manifest

It saves a lot of energy when you don't have to link to new files in your project manually. You don't even need to keep track if you ever have to move a file. All you have to do is to add "?flush=all" and new or moved files are recognized instantly.

Development and debugging tools

Nothing can beat a fully fledged debugger. But on the other hand, not every webserver you run across has xdebug set up and in some cases it is not even possible. We sometimes do contract work for clients who don't have root access to their boxes. In situations like these, we don't want to miss the built in SilverStripe debugging tools. You can learn more about them here.

PHP Command Line Interface (CLI)

This is one of the most inconspicuous features. One of our clients, an online pharmacy, sells more than 300,000 products. Prices and availability are synched with a back-end system regularly. Using the commandline, you don't have to worry about things like "maximum script execution time". It just works and does not block precious webserver processes.

Synergies

Not exactly a built-in SilverStripe functionality, but by far the most powerful feature. You can combine other community modules like forum module, newsletter module or blog module along with SilverCart to create a unique shopping experience for your customers. With each additional module that is available for SilverStripe, all existing modules instantly become more precious. This makes SilverStripe greater than the sum of its parts.

Depending on the projects you work on, I assume that you do have a different perspective. What are the hidden SilverStripe features that boost your productivity?

Congratulations to the Creators of the Top 5 Themes

Thu, 23 Feb 2012 15:02:46 +1300

Voting for the Theme Contest has officially closed. The top 5 themes and their creators are:

cloudy by Anselm Christophersen
simple by Sara Tusar
simpli by Hannes Wizany and Zauberfisch
silverbride by Simeon Stamenov
sunrise by Matt Bailey from GPMD

Congratulations! You’re already guaranteed one of the five prizes that come with the contest. Now it is in the hands of the judges to decide on the order of the top 5. All themes are very good, and I am relieved that I’m not the decision maker of the final winner.

Our judges will have their say on the themes this week and we will announce the final winner for the default theme of SilverStripe 3.0 early next week.

Thanks a lot to Tom Coates, Eduardo Cesario, Brice Dunwoodie, Joshua Turner and Felipe Skroski for checking out the themes. This will be a hard choice. I don’t envy your job.

Whatever the decision; I know that the default theme will be a good one, and that is a great accomplishment for the SilverStripe CMS and our community.

In saying that, I also have to say that everyone here at SilverStripe and Bluehousegroup is very impressed by the high quality of the the themes we received. There were so many very good themes in the run and it is shame that we have to choose just one.

Every contestant who sent in a fully coded theme will get a beautiful SilverStripe T-Shirt that the lovely Brooke is currently working on. If you haven’t sent your code in yet, but you want to be in for a T-Shirt, then please send the code by the end of next week.

All complete themes from the contest will be available in our theme gallery for SS 3.0.

The SilverStripe CMS and the community gained a lot with each and every entry. A selection of good themes makes a CMS so much more attractive to every user. You are all evangelists for the SilverStripe CMS and Framework. In the end, we are all winners!

THANK YOU FOR BEING A PART OF IT!

Wellington's February SilverStripe Meetup

Wed, 22 Feb 2012 10:57:12 +1300

A big thanks goes out to everybody who came down to Molly Malones last week for our February Wellington Meetup. We pretty much packed out the Blarney Slone room with 35+ guests attending. It was an eventful evening where we dabbled in code, recorded some Q&A style snippets on why you love SilverStripe, and checked out the top 5 Theme Contest entries. An awesome evening had by all, over some delicious nibbles and well deserved drinks.

Sigurd Magnusson kicked off the event, followed by SilverStripe Developer Stig Lindqvist who expanded on what to expect with the arrival of GridField in 3.0.

Stig talks about GridFeld in 3.0

NB: Link to GitHub repository to come (Stig is currently on a plane somewhere between New Zealand and South East Asia. Lucky for some!)

If there’s something you’d like to hear or speak about at our next meetup in January, get in touch through the comments, via Twitter and Facebook, or email kerstin@silverstripe.com. We’d love to hear what you've been up to with SilverStripe. If you haven't already, join our meetup.com group for regular updates.

In Defense of Frameworks

Thu, 16 Feb 2012 16:56:23 +1300

Guest blogger Josette Rigsby has over 15 years experience in leading technology teams and delivering solutions. She has a special interest in enterprise architecture and emerging technology.

PHP has ranked as one of the most popular programming languages for over a decade. The loosely typed language has a long list of built-in functions, simple syntax and very few rules, which makes it a “go to” tool for countless developers. PHP’s ability to get things done fast continues to attract legions of new enthusiasts, which is why it is a bit surprising that the PHP development community is still divided regarding frameworks.

Everybody’s Doing It?

The buzz around frameworks like CakePHP, Zend, CodeIgniter and even SilverStripe’s recently decoupled framework (formerly known as Sapphire), might give a casual observer the impression that the majority of PHP developers have embraced frameworks to standardize and speed their development.

They haven’t.

The recent MicroPHP Manifesto, which passionately argues against the current direction of most popular PHP frameworks, has refocused attention on the topic. Although the manifesto subtly states frameworks aren’t “necessarily bad” multiple times, you could easily get the impression that PHP frameworks are large and complex code beasts that eliminate the key benefit of the language- simplicity. Armed with this knowledge, you could then shed the oppressive constraints of the framework you loved only three months ago and become one with the code – rolling your own functions and stringing together micro frameworks to build an application that reflects your true spirit.

Slow down there, tiger.

Why Frameworks?

Frameworks aren’t all bad, and you should not discount frameworks just because they require time to learn or slightly increase complexity. If your goal is to create SOLID instead of STUPID code, leveraging a framework is often a good choice. However, there are scenarios where you should avoid frameworks:

Industries or organizations where regulations or policies discourage or prohibit use
Small or simple sites with mostly static content
Applications with exceptionally demanding performance requirements
Projects that involve making only a few enhancements to a large and established code base

For everything else, you should at least consider using a framework.

Using a framework is not without costs. You must take the time and effort to select, learn and eventually upgrade the framework. (TIP: If you are on a team with more than 2-3 people, consider having a lunch and learn to accelerate the process.) Although frameworks typically handle the most common scenarios, they may not address your specific use case. If this occurs, you will need to invest time in figuring out how to solve the problem. Many frameworks include extension mechanisms to make adding functionality easier. Finally, leveraging a framework means giving up some control. You must trust that the creators of the framework leveraged good design practices. You must trust that they tested. You must trust that they will not make breaking changes.

No tool is a silver bullet, but if you select a popular framework, you are likely getting a better product than you would have created internally. Many frameworks, like SilverStripe’s, are based on years of experience implementing content management functionality across multiple industries and organizations; unless you are lucky, your project team doesn’t include the same depth of experience. Further, many open source PHP frameworks have hundreds of contributors and thousands of users that provide a rich source of collective knowledge and peer review. This usually results in a solution with fewer defects and a better design.

A better code base isn’t the only benefit of leveraging a framework. Frameworks can:

1. Standardize Architecture – Most frameworks incorporate design (e.g. decorator) or architectural (e.g. MVC) patterns. Using the framework incorporates the pattern into your project. Additionally, frameworks can impose other structural constraints like file system organization, which make it easier for multi-member teams to deliver a solution. Micro frameworks can provide value in this area, but if you need to use more than one, you may have to deal with conflicts and inconsistencies in how they are organized. Obviously, using a framework isn’t the only way to achieve architectural consistency, but a framework can make it simpler.

2. Minimize Infrastructure and Utility Development – Frameworks often implement infrastructure concerns like caching, data connections, logging and security. These commodity features are required, but don’t significantly contribute to business value. If you don’t feel an urge to twist wires for your own USB cables, you shouldn’t feel a need to write lines of code to produce a log file. Don’t reinvent the wheel; spend your time designing and delivering core solution features.

3. Provide Broad Support Options – If you write your own framework, you and your team are the only source of knowledge about its use. If you use a framework you get forums, documentation, other users and potentially third party solution providers to help you solve problems.

4. Reduce Staff Onboarding Time – If you select an existing, widely used framework, it is possible to add staff that already know the framework. This reduces the time and cost associated with onboarding new resources. You should not underestimate the value of this benefit. Labor is significantly more mobile than in the past. It’s not uncommon for all members of an original implementation team to leave an organization before an application is retired. When there are no humans available to guide a new developer, the use of a framework can provide tremendous value.

5. Reduce Technology Debt – One of the benefits of frameworks you might have overlooked is reduction in technology debt. Teams often eliminate items that don’t contribute directly to business value (e.g. configurable logging) to complete a project on time. Unfortunately, these small concessions can have large and long lasting negative impacts. Using a framework allows you to get many of these often omitted features without investing the time to design, develop and test them.

I am not suggesting developing custom code or using a micro framework is bad. Every problem is different and these techniques are the right solution to some problems. However, sometimes implementing the fastest easiest solution on a micro level can result in complete chaos at a macro level. Do you use a PHP framework? Do you feel that it has benefited your solution delivery? We would love to hear your thoughts.

The Trials and Tribulations of a Freelancer

Wed, 08 Feb 2012 10:26:05 +1300

Guest blogger Ryan Wachtl is an independant US-based web developer and runs the SilverStripe user group in Madison. Prior to this, Ryan wrote about SilverStripe PayPal Mini Cart Integration.

I recently celebrated my fifth year of freelancing as a web professional. This had me thinking about how I’ve grown over the years, both personally and professionally, and I’ve learned that, as a freelancer, the lines often blur between the two. Many of you may also freelance, either full-time, part-time, or on the side. You may have left a corporate or agency job in pursuit of greater control and more freedom, or maybe you’ve never freelanced, or like me, maybe you’ve always freelanced. Regardless of your current situation I hope you’ll find something useful to take away from this as I share my experience with you. At the end of this post I offer up my advice to any struggling freelancers out there.

First I should clarify what I mean by I’ve always freelanced. This has been the case ever since I found myself, somewhat unexpectedly, working in the web industry back in 2007. I had worked for a hand full of employers prior to that, but they were in unrelated areas like retail, horticulture, and even in a lab. Before I fell in love with web technologies I was studying to be a scientist, specifically in the field of plant biology. I still try to stay current in the field, and I did ultimately graduate with degrees in biology and human biology, but about a year prior I took on my first web project, one that would set me on a new path. My friends had just started a bicycle company and were in need of a web presence. I had hacked together a site or two before this in 2000/2001 (before web standards had become wide spread), but I was turned off by all the inline font tags, table-based layouts, lack of good CSS support in browsers, and the horrible abuse of JavaScript. My friend's new company website was my first paid web gig and the one that ignited a new passion inside me.

Shortly after my first paid project I left my part-time job and set out to self teach myself as much as I could about HTML and CSS over the next three months. I spent the following year taking on a few more projects, adding Javascript and PHP to my tool belt, all while finishing up my last year of college and a rather large undergrad research project. In the summer of 2008 I graduated and was sent into the world to fend for myself. Rather than continue onto graduate school or take an entry level job in biology, I set out to pursue a full-time career as a freelancer. Little did I know that I was in for some challenges.

In the beginning

Things did not come easy at first. During my first couple years I struggled with time management, work/life balance, and had my share of failed projects and client relationships. I found myself so obsessed with productivity that I was actually spending more time trying out various management tools than I was doing actual client work. I wasn’t entirely confident with my skill level so I would price out projects based on a low hourly rate and then quote a flat rate for the project. This put me in a position of working long hours for little pay and in the end I found I was not getting a great deal of satisfaction from my work. Accepting calls from clients at all hours of the day and stringing out the length of projects to offer a false sense of job security had me questioning whether or not this freelancing thing was really for me. My health started to decline due to all the stress (I had no health insurance at the time), I started to feel isolated, and I had nothing to show for it. I knew that if I was going to survive as a freelancer, I needed to figure out how turn things around.

Discovering my worth

The first step I had to take was to figure out what my time was worth, this included being realistic about how many billable hours I could actually fit into a day. I found out that freelancing is about more than just producing designs or writing code, I needed to handle accounting, marketing, and other business related housekeeping tasks, not to mention the daily emails that come in after you’ve worked with dozens of clients over the years. To get at my current hourly rate I worked backwards, first setting a revenue goal for the year and breaking that down into the number of days I wanted to work and the percentage of time I could invoice. About 60% of my work day is billable now, if you’re doing better than this congratulations you’re ahead of the curve. Getting my rates and time management sorted is something that just took time, I needed the experience to be able to estimate project scope and time more accurately, and gain the confidence to ask for what I was worth in return for my services. I’ve been able to double my revenue over the last two years and while I’m still not getting rich, everyday I feel like I’m moving more and more in the right direction. When it comes to matters of time and money I think Alan Weiss put it best in Million Dollar Consulting:

“Wealth is not money, but discretionary time. You need to make the money necessary to have maximum discretion as to how you spend your time”

Finding my niche

The second step that really turned things around for me was finding my niche. I had been building websites on SilverStripe from the beginning (after a long search for a quality CMS), but I didn’t actively seek out SilverStripe related work and thus found my time spent working with other platforms like WordPress, Magento, and Drupal, at the request of clients. At the onset of 2011 I decided to focus solely on providing front-end and back-end development for SilverStripe projects. Shortly after, I organized a local SilverStripe user group and started to seek out agencies that were using SilverStripe who needed help with overflow. I still work with a few of my own clients, but making the switch to working on portions of a project, as opposed to managing an entire project, has cut down on a lot of my non-billable administrative work and allows me to focus on producing quality design and code. I now have nice working relationships with a handful of agencies across the United States and I get to pair my skills up with other great designers, developers, and strategists.

The three constraints

And finally, the other major step I took, or more so the final hurdle I overcame, was to improve my project management skills. Once I realized how the three constraints in project management (scope, time and cost) impacted the ultimate success of my projects, I was able to gain control of my schedule and prevent projects from going horribly awry due to scope creep, unrealistic deadlines, and other conflicts that can arise within the three constraints. Early on I had a few projects that either failed to come to completion or failed to perform post production because I tried to fulfill a clients wish list of features with whatever budget they had. I am now wiser, and instead of focusing solely on features, I start all new projects with a list of goals (both user and business goals) and figure out how best to accomplish those goals within a given budget, or in some cases, what budget I feel is required to make it a successful project. I’ve been able to steer clear of problem projects when I see that a given budget does not match up with the expected results. For me, a successful project is more than just shipping a product and getting paid for my work. I need to see that the small businesses, agencies, and non-profits that I work with are getting value from my work and in turn are achieving their goals. Forming quality long-term business relationships and seeing other businesses grow as a result of my work is how I found job satisfaction.

Forward

I’ve come a long way, but I’ve still room to learn and grow. I have yet to put together a decent portfolio and should stop making excuses about doing so. I can be kind of hard on myself and keep thinking; my next projects will be so much better and they will be worthy of show. I really just need to start putting myself and my work out there more. While I’m really comfortable on the front-end, I’m still working on becoming a better programmer, like getting more into test-driven development (something SilverStripe is already nicely setup for) and delving further into object-oriented programming with both Javascript and PHP. I would also like to share more. I owe much of my success to all those that I’ve learned from. Far too many to name, but from your personal blogs, to stack overflow contributors, and to all of you in the SilverStripe community, I sincerely thank you. I need to return some of that, I need to take a little extra time to write about the solutions to the problems I come across.

Lessons Learned

My advice to struggling freelancers.

Raise your rates. You’re likely not charging enough. After I raised my rates I gained more respect from my clients. It also encourages me to work smarter and be held accountable for delivering something that warrants said rates. You may need to juggle several different rates as you ease existing customers into it. Be honest and upfront with them, explain why you made the change and how it servers them better. Look at other trade and professional services in your area (plumbers, electricians, computer repair, etc.), I’ve found it a good gauge for setting hourly rates for a local market.
Get out and socialize. Let’s face it, freelancing can get lonely. Get out to conferences, they can seem a little cost prohibitive at times but the connections you make there are more than worth it. Join Meetup.com groups, present at them, or form your own if there are none. I’ve found that one of the best ways to learn new skills is to try teaching them to someone else. You’ll quickly discover your core competencies, and see where you may need improvement. Also check your area for co-working spaces.
Specialize, but not too much. I’ve found success in directing my efforts towards all things SilverStripe, but I also maintain a generic skill set. If you find yourself deep into one particular framework or project, don’t lose sight of the underlying technologies used in the project. For example, I work with jQuery a lot, but spend time now and then making sure I understand the abstraction and write vanilla Javascript. That is, decouple your proficiencies from the context of your tools and you’ll have a lot more job security and flexibilty.
Build long-term relationships. Take care of your clients and they will take care of you. As a freelancer I’ve found that the majority of my work comes through direct referrals. I don’t believe in bad clients, but I do believe in bad designers and developers. Most client relation problems are the result of poor communication. It’s your job to educate the client and clearly set expectations. But yes, sometimes it just doesn’t work out, learn from your mistakes and move on.

Well, that’s my story (in short). Are you a freelancer? What has your experience been like? Leave a comment below or hit me up on Twitter. If you find yourself struggling like I was, get in touch and maybe I can offer some more advice. Despite it’s hostile nature, freelancing can be a very rewarding experience.

The Magic of Community Work

Thu, 02 Feb 2012 12:21:13 +1300

Last week I realised that I am asking you guys quite a bit these days; more pull requests, themes, blog posts, hackfests and meetup presentations. And yeah, every once in a while there is yet another community member who is stuck and needs your help.

I can tell you are getting tired, you have a full time job where you do overtime already, a nagging wife or husband at home and the kids don’t let you sleep either. And then Schuman comes along and wants you to do yet another thing!

My enlightening moment came during a Twitter exchange with Ben Tucker a few days ago.

SilverStripe @silverstripe
Anyone working on a theme for the contest? Anything else we can help with? What does it need to make your entry possible?#themecontest ^KS

Ben Tucker @SticksTucker
@silverstripe The contest needs to do my job, move my house, and eat and sleep for me so I can have time to put something together!#toobusy

SilverStripe @silverstripe
@stickstucker It is a great CMS, but I am afraid it doesn't have magical powers. Wish it could be the answer to all our problems. ;) ^KS

Ben Tucker @SticksTucker
@silverstripe Fair enough. Keep those things in mind for SS4 though, yeah?

Seriously, I wish I could do magic tricks and get an awesome CMS and Framework 3.0 out for you and solve all your private and professional issues at the same time. All that without you having to move a finger. That would be awesome! I would have a Tooth Fairy tiara, a magic stick and wings on my back.

Well unfortunately our innocent days of Fairy faith are over and we all know that whatever we want in life takes hard work to get it. Now it is all about setting priorities, because each day has only so many hours.

Investing unpaid work into open source is then often not on the top of your priority list. And I don’t blame you. You are not alone; the SilverStripe teams working here in the office have the same prioritisation issue. Paid client work versus free work for the greater good. Sounds like an easy decision when bills and employees need to get paid, right?

We keep hanging in there, so that SilverStripe 3.0 will see the light of day. We’ve been working on it for two years now. The babe is almost ready. It just needs to grow a little further. We believe it will maybe not change the world, but will be a massive step into the future of web development.

SilverStripe is the tool you use daily to create the most beautiful and useful web applications. You use it every day and you know it inside out, you know its strengths and its weaknesses. You can tweak and model it and make it do whatever you want. (That’s probably more than you can say about any other partner you’ve ever had). And it needs your love to keep shining and working for and with you.

There are a few among us who work very hard to keep this tool alive and kicking. Huge thanks to our friend from Austria; @Zauberfisch. He worked long hours in the recent weeks on a more user friendly upload control for SilverStripe 3. (@Zauberfisch; I wish I knew your name, but you have beautiful scales.)

Here is what Zauberfisch has to say about himself:

I am actually an employee, but the company uses SilverStripe, and I just came to love SS, so now I spend a big part of my spare time on it. Besides the websites I build at work, and private for friends and such, I am always in #silverstripe on IRC to provide support. I helped lx-berlin with the NetefxValidator, which we now maintain together. And I am planning to do a lot more work on SS, and also modules. Coding is my work and my hobby. I guess that’s it, there is not much more I can think of right now. Oh yeah, and people can vote for me at the SS Theme Contest this weekend.

Other top contributors of the last 6 months:

Wolf Vollprecht, Frank Mullenger, Jeremy Thomerson and Dominik Beerbohm.

Huge thanks also to Will Rossiter who moved on from SilverStripe as a company, but didn’t leave the tool or the community behind. He’s still a big contributor to the tool development and the community. Thanks to Simon Welsh who makes great improvements on the framework and never misses a SilverStripe hackfest. Thanks to all the SilverStripe supporters helping out in the forum, the developer mailinglist, on Twitter and Facebook.

More stats on the top Framework contributors and the CMS contributors.

I am sorry if I missed anyone, you are all very important; you make the tool and the community grow and develop. And the more evangelists we have the bigger the community and the more shoulders we have to shift the work.

Don’t give up. You make it work and keep the engine running and if you are stuck then go and ask. I’ll do my best to get you help, if you haven’t find it already in this great community.

Find tickets to work on in our bug tracker - here's a couple marked as "easy". And check out: http://silverstripe.org/contribute/ for more ways to help out.

In the meantime, I put my useless magic dust back into the drawer and wait for your themes, because the Theme Contest is still running!