Frontend Architecture

[rjmackay]

This is a big chunk of discovery work to figure out what libraries, etc we're going to use in building the frontend. A few questions / items to address:

• How do we handle localization?
• Templating
  • handlebars
  • mustache (https://github.com/zombor/KOstache)
• JS driven frontend UI
  • Should we use a framework?
  • Backbone
    • Backbone.Marionette
    • Chaplin
    • Thorax
  • http://emberjs.com/ EmberJS
  • Do we need
  • View models
  • Model binding
  • JS coding standard
  • Closure compiling everything
• Beginnings of JS/PHP SDK ?
• How to handle users w/o JS? or on slow connections?
  • Do we deliver a basic UI through just PHP/HTML/CSS ?
  • Do we just insist on JS?
• Themes - how do these hook in?
• Plugins
  • how can these add/modify the UI?
  • what do we need them to be able to do?

[rjmackay]

ping @dkobia thoughts on what else this needs to cover?

[rjmackay]

My thoughts on how this works:

• We share mustache or handlebars templates between PHP and JS.
• Render pages with PHP but handle live updating through backbonejs (or some extension of backbone)

Deliverables:

• Create basic template structure (based on current design mockups)
• Make initial decisions on: JS frameworks, Templating engine
• Basic posts list
  • Post list should be populated in HTML from PHP
  • Post list should update via AJAX calls to the API

Extra considerations (maybe done in later features):

• Compiling CSS + JS
• Localization
• Security.. Output sanitization/filtering, Content Security Policy.

[dkobia]

Throwing a couple more links into the fray:

• https://github.com/laurent22/Kohana-Mustache (3.3 compatible)
• http://smacss.com/ via @middle8media

As for JS Frameworks, there are few options:

• Backbone
• EmberJS
• AngularJS

Also:

• The default layout should definitely be built in as a theme itself and probably Mustache based?
• Also maybe we can do javascript based bandwidth detection and render a lighter theme?

For Events/Hooks (re:plugins)

• We could use the familiar Kohana Event module (https://github.com/Zeelot/event) -- rewritten for 3.3 (https://github.com/Zeelot/event/pull/2)
• I've also seen a few Symfony based dispatchers like: https://github.com/BRMatt/Kohana-Dispatcher -- slightly more advanced but not PSR0 compatible.

[sethburtonhall]

I'll throw a few more things in the mix...

• Spine.js - Front-End JS library. This could be a lighter framework and maybe easier to work with. No experience, just wondering.
• I have more experience with Handlebars, but could adopt Mushtache fairly quickly.
• I use SASS and Compass to process CSS. Variables, extends, mixins, includes ... the works. This makes revisions and updates a breeze.
• Along with SMACSS, I also approach CSS this way - https://github.com/stubbornella/oocss/wiki - basically everything will be modular, reusable and scalable, so we can update code faster and decrease spaghetti code.
• I usually develop static sites with Jekyll. http://jekyllrb.com/ - but may not need this depending on the architecture.
• We should definitely use a responsive grid. Something like https://github.com/csswizardry/csswizardry-grids which was extracted from https://github.com/csswizardry/inuit.css/
• Combine all this into patterns/style guide for reference, customization and cleaner code. Like http://www.starbucks.com/static/reference/styleguide/ or http://foundation.zurb.com/docs/ or http://twitter.github.io/bootstrap/

and you have a kick as web app!!!

[sethburtonhall]

Once I talk with Robbie on Monday and grill him with questions :) I will have a better grasp on the flow and architecture and be able to move forward with more confidence.

I am totally stoked to be developing this platform and solving problems with this team .

[rjmackay]

So I lost a day or 2 digging into JS frameworks.. some thoughts from my research:

• whatever we use we want to compatible with a strict content security policy, mostly this means we need to precompile JS templates to avoid use of eval. Backbone, Ember and Angular can all do this. Angular does it out of the box.
• AngularJS: I'm not fond of their html attribute style templating
• Ember looks promising, but definitely more targeted at building a single page app.
• Backbone (or possibly Backbone.Marionette)
  • could be easiest if we're going for a mixed PHP/JS approach.
  • Backbone can be a mine field of addons etc.. hence I'm tempted to head towards one of the more opinionated extensions like Marionette to narrow our choices.

Mustache is basically handlebars with slightly less features. I'd be happy with either but can't find much support for Handlebars in PHP+Kohana. I've started playing round with https://github.com/zombor/KOstache/ for mustache templates in PHP.

"Also maybe we can do javascript based bandwidth detection and render a lighter theme?" -> would be awesome for a 3.1/3.2 feature.. along with offline web app support!

Events in Ushahidi 2.x always felt like a hack to me.. but might need it or an equivalent.

I've started getting a SCSS/Compass build process set up using kohana-media and minion-tasks-media https://github.com/Zeelot/minion-tasks-media/ There are a couple of contraints here:

• We need to keep build tool complexity as low as possible for our deployers/themers. We can use css/js compress, compass etc. But need either fallbacks, or automatic building through PHP.
• I'm trying to avoid the security fail from 2.x writeable media/uploads directory in the webroot. Which means using something like kohana-media to handle CSS/JS/Images.

[rjmackay]

@middle8media I also played with http://semantic.gs/ grid system. But I'm happy to let you drive the choice on grid systems.. whatever works for you.

Jekyll is awesome but not really an option since I'm limiting our stack to PHP since our deployers are often on crappy hosts etc. That said I'd love to use Jekyll on a custom project to build out a story telling site around Ushahidi core.

[sethburtonhall]

@rjmackay Yes, http://semantic.gs/ is great! I have used Susy which is similar. Keeping the grid out of the markup is the best. I saw we go this way.

Yeah, Jekyll is sweet, but not for this project. Maybe we can use it somewhere else.

[sethburtonhall]

So today I found a really cool repo that generates a dynamic pattern library/style guide using a simple php script and the project's existing CSS codebase

Here is the flow

• Update and compile CSS as normal
• add html snippets to the /patterns folder
• pattern library updates at url (which could be custom like ushahidi.com/3.0_styleguide or something easy)

To update all we have to do is style the SASS and compile to CSS as usual then add any new html snippets. Very cool and easy to customize, maintain and scale. This is the best solution I have found from all my research and hope to integrate it into the 3.0 Front-End Architecture.

https://github.com/adactio/Pattern-Primer

We just need to figure out how to maintain exclusive control and display to both Ushahidi team and the public. I have a few ideas that revolve around hosting on Github Pages or service hooks.

Any disadvantages?

• patterns are displayed in order of patterns folder, which is alphabetical. Although this could be customized within php script. Is this even a problem?

others???

[sethburtonhall]

of course this can and will be styled differently and customized to our needs. But the dynamic generation and scalability is the bomb.

[rjmackay]

RE: pattern primer, my main concern is that its a PHP script outside of Kohana, which we don't really want. However given all its doing is generating a quick listing of patterns, I think we could rewrite that as a kohana module really easily. That way deployers could easily enable disable the patterns list too.

[sethburtonhall]

Example Screenshot:

http://cl.ly/PJKq

[sethburtonhall]

@rjmackay that is interesting. I am not familiar with Kohana, but I trust your judgement.

It would be easy for internal dev team to keep updated, but would it be too much to ask for our deployers.

I still need to wrap my head around what our users want and how we envision our patterns library.

[sethburtonhall]

This is another great example and resource from Brad Frost

http://patternlab.bradfrostweb.com/

I am looking into how he developed this

[rjmackay]

@middle8media are you using SASS with indented format or CSS style format? ie.

$blue: #3bbfce;
$margin: 16px;

.content-navigation {
  border-color: $blue;
  color:
    darken($blue, 9%);
}

.border {
  padding: $margin / 2;
  margin: $margin / 2;
  border-color: $blue;
}

vs

$blue: #3bbfce
$margin: 16px

.content-navigation
  border-color: $blue
  color: darken($blue, 9%)

.border
  padding: $margin / 2
  margin: $margin / 2
  border-color: $blue

[sethburtonhall]

I am using SASS with CSS style format

$blue: #3bbfce;
$margin: 16px;

.content-navigation {
  border-color: $blue;
  color:
    darken($blue, 9%);
}

.border {
  padding: $margin / 2;
  margin: $margin / 2;
  border-color: $blue;
}

[sethburtonhall]

What are your thoughts on RequireJS in terms of this project?

I would like to use it to keep my JS/jQuery modular, especially as the app scales, but I don't have tons of experience with it and I am wondering how it would effect things on your side.

Let me know your thoughts on working it in.

[sethburtonhall]

Two informative RequireJS links

http://devblog.wesmcclure.com/posts/why-requirejs

http://www.sitepoint.com/understanding-requirejs-for-effective-javascript-module-loading/

[rjmackay]

I haven't had time to really digg into requirejs .. it is being used for Crowdmap. But really.. use whatever gets you up and running fastest. If something doesn't fit we can work that out later.

[sethburtonhall]

Awesome, I think it will be good for 3.0. I am on it.