Category: Behind the scenes

  • The beta testing period is coming to an end

    For a bit over a month now, we’ve had some friendly external folks helping out with testing our site and giving us valuable feedback. This is for me, unfortunately, something that I haven’t done a lot professionally prior to this project. I can definitely recommend anyone to get an outsider’s input on what you’re creating.

    Normally after a certain amount of time spent on a project, you become too involved in the product. It turns out to be impossible to stay as objective as you wish you could. And besides that, it’s as if you slowly but surely walk away from watching the big picture and instead you’re getting caught up by all the tiny details. The most meaningless little button can suddenly become your brain wrinkler for an entire evening. So it becomes a bottle neck, and eventually (after too much time spent), you realize that you have to move on. Because you lost momentum. Again.

    Will people even notice the time you’ve spent? In most cases not, I guess. But as the swedish saying “djävulen ligger i detaljerna”. (I couldn’t give that a decent translation, however…) all those tiny details eventually ends up enhancing the overall impression of the product. The tricky part is definitely to find a good balance in a project with limited time and resources. You want perfection, but you can’t have that, so what features are the most important etc.?

    Therefore comments from an outsider, a person with a pair of “fresh eyes”, is invaluable. They give you some sort of reality check. What do people actually pay attention to, the first, the second or the tenth time they’re visiting your site? The things that I pay attention to the 500th time (which probably isn’t a bad estimate on my amount of visits), can alter quite a lot from the first timer.

    So when you step back and zoom out a bit, you might realize that the core idea/concept isn’t communicated as clear anymore and that you might need to redo pieces or even start over completely.

    It’s hard though, “killing your darlings”. The sooner the better is probably the best advice here. It stings more to redo an entire section of a (nearly finished) full functioning website and go from scratch than it is to throw away a rough sketch. So again, get input early on. It’ll make production time much shorter.

    Alright, before I’m done; a BIG thanks to all the people that have helped us with insights, ideas, feedback etc. Extremely kind of you to give some of your time in order to make this a better product, your services are very much appreciated.

  • Let’s design this baby!

    Let’s design this baby!

    Today me and Robin had had our first design meeting in Stockholm.

    I’m proud to say we managed to stay quite focused on HOW we’re gonna work. But of course we could’t stay away from making some rough logo drafts.

  • Underneath the surface

    This post is a tribute to all the great, license free and open source, code we’ve used to get this site up and running. These platforms, plugins, scripts, snippets and apis etc. have saved me as a developer a ton of time and hardship, so I think they and their authors deserve some acknowledgement.

    What has really come to be true during this project, which web-production-wise has been somewhat stressful at times, is that you really shouldn’t write everything on you own. Better spend that extra hour on researching wether someone has already built the stuff you’re supposed to be building than wasting valuable production hours reinventing the wheel.

    First of the wonderful WordPress 3.3.1, which since the 3.0 release has come to be more and more of a publishing platform, rather than just a blog tool. All of the backend features are driven by or based off of WordPress. The cms side has also been largely rebuilt to work faster and easier than before. Post types makes it a lot better to organize different kind of content, (in our case methods, videos, glossarywords, and blog posts). With the $wpdb class (since 2.8-ish) plugin development becomes a lot more hassle free, and made the progress of building the improve-articles/write-your-own-article feature a lot less complicated.

    On the front end side, the best buddy is as always jQuery. And since we decided to for a HTML5 markup combined with partial loading for this site, I was glad to read that version 1.7.1 had built in support for html5shiv for appended data. With the ajax loading and a tiny if statement in the back end which disables the rendering of the header and footer, the browser loads a lot less data and it doesn’t have to reload the the entire page every single time. This is for all you non IE users.

    Modernizr is letting us use html5 markup cross browser, does all the scrip loading and lets us detect a couple of important browser features.

    Since we wanted to keep the site shareable and google friendly, the shebang solution wasn’t really an option. Instead we used the HTML5 history API to “fake push” the requested urls without having the browser going there. For this feature, I had a ton of help from the jQuery plugin History.jsBenjamin Lupton (not to be confused with jQuery history plugin, or jQuery-history).

    For the stylish animations when filtering and sorting of all the methods and videos, we used the jQuery plugin called Isotope by David de Sandro. That plugin does a ton of job for you and is easy to set up. And it looks pretty dope, right?

    To make all the animations on the site look smoother, we’ve worked with another (drumroll…) jQuery plugin (tadaaam!), called animate enhanced by Ben Barnett which let’s the browser (again, non IE) play with stuff like css3 transitions, instead of the heavy js-animations.

    Data and content wise, we’ve been working with the Facebook API, Twitter API, Youtube API, Vimeo API and we have some future plans on working with Wikipedia API and Google analytics API. For the improvement form WYSIWYG we used the old but customizable widgEditor by Cameron Adams.

    While I realize that this blog post hasn’t got much to do with the how aspect of the project, I have at least given a small thanks to all the good developers that directly and indirectly have helped the Project of How moving forward. Not only have I saved time by using all these plugins, scripts, snippets and apis etc. but I’ve also learned a hell of a lot from just reviewing other peoples code. Hi 5 to open source!

  • Applying for funding, part 1

    Applying for funding, part 1

    In may 2011 we started to talk more concretely about Project of How.  Emelie and I met up many times that summer. Google docs and Skype was the tools we continuously worked with during the application phase. Google docs allowed us to work simeoltaniously on the text together sitting next to each other or having a parallel discussion on Skype. These two where valuable tools in shaping the project. (later I have also been a fan of having facebook groups for small project updates).

    As we wrote the applications new questions and new ideas came up. It was a long process and the progress of shaping the text also developed the initial ideas and the vision regarding the project. In July we sent in the first application to Kulturbryggan. But we proceeded to write the other applications throughout the summer.

    We had many ideas regarding funding options but mainly we decided to go for applying for government funds. The primarily reason for that was that we wanted to create an open independent platform without ownership that made us blindfolded or demanded commercialization of the open library we wanted to create.

     Over the past years I have been writing numerous applications and I would say there are a couple of common pitfalls that hinder you to get funding:

    1. The project is not good* enough.
    2. The project is unsuitable for the fund where you apply.
    3. The idea is not described in clear way in text (application), speech (presentation/pitch) or/and visual shape (graphic design of application/presentation or process descriptions).
    4. the funders don’t feel confident about that you could carry out the project in a good ways.

    Checklist to avoid the common pitfalls:

    1. Develop the idea, develop again, and again! understand (what, how, when, where, who and why). Could you describe the project in one sentence?
    2. Check the goals for the fund. Is the project corresponding to the focus areas of the fund?
    3. Work hard on describing the project in a clear and good way. If you yourself understand your project idea it becomes much easier to write the application. (see my ideas about the seven starting points.
    4. Be good at describing and be sure to find out WHY you would be competent enough to carry the project out!

    Creating a raw project description with the seven starting points!

    After doing all this a sat down this winter and drawn down my ideas about the process. Something that have been key in shaping the project and the application has been the Starting points. To define the starting points are a bit like having raw material for creating an application for funds but it would also suit as a good point to create a business plan, a project plan or any presentation of the project. The starting point describe your project. And it answers ALL the journalistic questions (what, how, when, where, who and why)

    I would build a raw description from seven starting points:

    1. Problem (what)
    2. Vision (what, why)
    3. Target group (who, why)
    4. Motivation (why?)
    5. Competences (what?)
    6. Partners (who, what, how?)
    7. Solution (where, how, what, who, when), this last one has to be built upon the other starting points!

    This is an illustration that illustrates the Starting Points as a part of the process.

    Working model on ideation

    If i would shape a new project i would go trough these steps to be able to define the project.

    Checklist to define the seven starting points, preferable in a workshop format:

    • Map up and understand the underlying problems (problem mapping)
    • Understand and map up the visions. What do you want to achieve?
    • Understand your drive and what motivates you in the project
    • Understand your competences and what you are good at, your role in the project (which skills you lack)
    • Map up the needs for partners or funding. (are you lacking skills or funding to be able to carry out the project?)
    • Who is the target group, do you understand them and what they want? Is the solution relevant to them does it solve their problems?
    • Explore Possible places methods and tools to carry out the project and go from problem to vision. This is the actual solution.

    Ask yourself if the idea is the perfect solution, turning today’s problem into tomorrows vision.

    If you can describe the idea in a clear manner that makes the idea easy to grasp your home! Can you describe the project in an oneliner?

     We decided to go for four different funding tracks.

    More advice to come in part 2.

    Cheers,

    Ola Möller
    Co-founder of Project of How
    Working at Idea Society