eZ Community » Blogs » Terry Duivesteijn » Road to eZ Market (1): the first steps

By

Road to eZ Market (1): the first steps

Monday 07 May 2012 8:52:50 am

  • Currently 3 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Note: This is a series of blog posts. You might want to read older posts first:

1) Ins and outs of product development for the eZ Market

----

As promised I will continue with writing blog posts about the release of our extension eZ Multitasking One into the eZ Market. My blog posts are an ongoing process, so if I miss out on any particular area you would like to know more about, let me know!

Parallel to my blog posts, my colleague David Ennis will describe technical details and challenges in his blog at http://share.ez.no/blogs/david-ennis.

In my posts I will try to chronologically list the steps we took on the ‘road to the eZ Market’. 
This post describes the (possibly very obvious) first baby steps we took before we did anything else. That’s why this post isn’t technical at all, but more a ground-layer for upcoming posts.

When we thought of creating an extension that would simplify content management in eZ Publish we had to make a lot of decisions. In retro-perspective I personally think the following issues were specifically important to us throughout the whole process, and that’s why I kick off with this post.

What was our idea?

We believed that all times during the process, we had to be able to explain our idea in one or two sentences. We wanted to make sure that later brainstorms or additions didn’t interfere too much with the original idea. So we wrote down our idea in order to be able to refer to it in the  months to follow.

Our idea was to “enable content managers to work more efficient and faster in eZ Publish”. During  later phases of the development process lots of new ideas popped up that could all have been great additions or new features. We indeed integrated some of these features into the final product, but a good share of them didn’t make it for our first release. Simply because we wanted to stick to the original idea, wanted to keep the complete project manageable, and we had been given a fixed budget from our director.

Engaging with end-users

We cooperate with quite a number of content managers and we have asked them what they thought about our idea and whether they would benefit from what we had in mind. We wanted our extension to be useful for content editors who work with eZ Publish on a daily basis, but we also wanted to make working with eZ Publish easier and more intuitive for beginners or infrequent users.  Therefore, we formed a small test-panel (three experienced content editors, three people who were new to eZ Publish and one infrequent user of the backend) and we asked them to demonstrate how they create, edit and manage their content by carrying out a couple of assignments.
Most of you will recognize our experience when we watched our test panel using the current administrative back-end for the simple task of moving folders, making the same corrections in multiple documents, and unhide series of items. I think watching them implementing endlessly repetitive routines we were forced to let go of our ‘developers perspective’ and saw how they were struggling with regular tasks in eZ Publish. For instance, as an experienced desktop-user and knowing my way around in eZ Publish I am pretty quick in editing 10 different articles. I simply open all  10 articles first in a new tab through a CTRL+Click on the ‘Edit in English (United Kingdom)’-link in the context-menus. Then I make the change per tab and publish the article. But we noticed it’s not that easy  for many content managers. They tend to follow the normal routine of ‘finding the article’, ‘clicking on edit’, ‘changing the contents’ and ‘sending for publishing’. This is nothing new, and  the predicted routine that people will follow. But as we were more and more confronted with this time-consuming routine followed by our test panel, we gained a lot of new insights that we could use for implementing our idea.

As a developer I think we tend to overlook usability and efficiency because we have to make choices for the sake of efficiency in programming that are not always the best solution for content managers. In fact, by exploring the backend as we did in the last year, we found a lot of examples where we saw that from a developers perspective the code was nice and well thought through, but from a content editors perspective really weird and time consuming.

What did we want to achieve?

We took our original idea, the results from the test-panel sessions and feedback from experienced content-editors and transformed it into to the following goals we wanted to achieve with our extension:

- a new nice, clean and uncluttered interface for editors without all those buttons and fields a content editor never uses
- daily tasks and routines that are supposed to be simple; make them really, really simple and efficient
- get rid of the many often repetitive steps in the editing-process and make the editor’s routines very easy and very fast

Time and budget

Our director was enthusiastic about the idea since the day we presented our idea to him and insisted that we would  manage the project as a ‘normal project’, with a budget, time allocations and a timeline. Our director took the role of ‘client’ and we would be the contractor. This way we had to manage the project as every other project for clients, which was critical to the success of our project. If we would have just started developing a product alongside our original work, we probably would have ended up with serving our regular customers (because everything they ask tends to have priority) and with a partially finished product.

We made a quote for our ‘client’ together with a list of deliverables, which can be summarized to:

- quick add and edit of content
- improved speed of the interface by using only the data we need at any time (AJAX)
- efficient searching for content (include drafts in tree and add filters for the content structure)
- new bulk actions (publish multiple drafts at once, (un)hide, assign a section, add location)
- edit multiple objects simultaneously
- drag and drop object relations
- always available content structure (including adding content to the current location)
- improved search and bookmarks
- color and font toggle for the visually impaired (one of the members of the test panel appeared to be color blind).

The total project was scheduled to be designed, developed, user-tested  and being certified between December 2011 and April 2012. We experienced some relatively minor delays, especially due to some technical challenges we encountered and not knowing how exactly the development process would evolve and what we could expect from getting certified for the eZ Market. More details later!

Although we thought about marketing strategies right from the beginning, I will discuss this topic in one of my later blog posts to make the series more understandable.

If you’re still reading so far, thanks! My next blog posts will describe the actual start of development of the extension and preparing for the eZ Market.

If you have recommendations or additions to this post, please leave a comment.

Proudly Developed with from