Openbravo User Guide is in place and is now “working hand by hand with us” getting thanks from the people.

At the same time documentation content is getting high appraisals when someone points to it, saying “read it here”. But would it be much more valuable tool if people around can find materials they want themselves!? Answering this better documentation search is one of the top requirements that appear in the documentation survey results.

So this time together with content polishing we were working on improving documentation outreach and I would like to share several tips with you on how to find your path through Openbravo User Guide. 

1. Follow the same path like in the application itself because documentation structure follows Openbravo application menu.

It is simple to remember but a bit boring and long path, especially now with a Quick Launch options we have in the Openbravo itself. Good news is that User Guide has short-cuts also.

2. So type down window / report / application area name directly in the wiki page URL. All User Guide articles are placed directly at the top level without any additional paths. That means if you need to find information about Goods Receipt or something else just type it:

3. Access documentation directly from Openbravo itself.  Clearly our on-line Help requires significant improvement from content and design point of view but it is a long term task. But having documentation resource that maps directly with the application gives us an ability to link to it from the Openbravo itself. So now (from MP10) on-line help page of each window has a link to the corresponding wiki article.

4. Use improved wiki Search. At first significant clean-up was done with about 130 articles deleted and 200 articles moved to the 2.50 wiki name space. 2.50 name space allows us to set lower priority for search engine for articles placed in it in comparison to articles in the Main namespace. It also gives a clear visual hint to those who read such articles signalling that they belong to the old release. As a result now search output is much more focused on a new User Guide content than on the old articles. Still for some cases it is not yet ideal because old articles inherit good ranking and even with lower priority set by us appear higher than some new articles. But it should improve with time as we use new User Guide. We will also be continuing to tweak search engine.

5. Be always in the context. At the top and the bottom of each article there is a “back” link to the application area documentation to which this window belongs to. This application area document contains a business process diagram (like Order to Cash) and describes the way particular window is used in the functional flow and introduces users to other actions they can do.

6. Dig deeper if required. Manually written documentation contains information about essential fields that are displayed on windows / reports. Common to all windows fields are not explained each time but just mentioned in the Common Concepts section. Self explanatory fields are just skipped. Anyway if you would like to consult full list of fields and their descriptions you can do so using Screens Reference. Now at the bottom of each window there is a link to the corresponding reference documentation. It is worth to mention that this reference contains not only all displayed fields description but also lists all hidden (due to Openbravo out-of-the-box simplified setup) fields.

We do believe all these measures will bring documentation closer to you. As always we are open to hear your feedback.

Finally I would like to say thank you to people who were helping to close this documentation milestone and especially to Asier Lostale who put main efforts on making these changes available.

Stay with us because during nearest weeks we will be sharing for your feedback first How toes on which we are working on.

Hi, yesterday we had another session with the Development Team. This time the topic was “How to build a View Implementation” (aka “Manual Window”)

You can grab the code of this example at: https://bitbucket.org/iperdomo/org.openbravo.training.manualwindow

Happy coding!

Update: I forgot to mention that this is the first part of a 2 session talk. And as some colleagues have mentioned, there are more elegant ways of selecting the Grid fields. We’ll see that in the next session. Stay tuned!

With the technology and interaction design well on their way, we´re now about to close the graphical design phase for Openbravo Web POS. It's going to look like no other Point of Sale you have seen before and sets a new design direction for Openbravo Mobile and Retail. Here's the design rationale.

Minimalist & direct: Openbravo Web POS features a minimalist design inspired by De Stijl and the Metro design language, that prefers content over GUI chrome. It uses straight and rectangular forms and is strongly typography based. The user is encouraged to interact directly with labels. For example, to add an item from the product catalogue, you just click the label (1). To reduce the amount, you just click the amount (2). There is no need for additional buttons and a minimum amount of taps is needed.
Light & flexible: Elements float on top of a background, emphasizing the lightness and flexibility of a web based application where the presentation layer is separated from business logic and data.

Optimized for modern touch screens: The new design makes use of modern touch screen capabilities that are offered by consumer devices such as the iPad but also increasingly by more industrial terminals. Products are browsed by swiping lists rather than using tedious next/previous or scroller bars. These are only rendered in case of older touch screens or mouse/keyboard operated keyboards.

Happy to be personalized & customized: Openbravo Web POS runs on anything with a browser - which means it must look good on all platforms and devices. It should also blend in with the retailer's shop and brand. The open architecture and use of standard web technology (HTML5) allows for easy adaptation for specific environments and even without coding, personalization should be easy. Colors and backgrounds can be matched with the company's corporate identity and adjusted to temporary themes.

Playful and proud to be seen: Most POS GUIs are dull looking, which is a missed opportunity because the exposure of these systems to staff and clients is high compared to other back end systems. POS systems take central stage in most restaurants and bars and retailers more and more let their customers co-interact with the system. Openbravo Web POS wants to be an appealing, fun and professional piece of software that staff and customers love to use and show. Nifty little design details such as the folded corner, animations, illustrations and intelligent messaging add to the experience. The exposure of the POS GUI to staff and customers is also an opportunity to communicate with them, through the GUI itself (e.g. branded themes), the message area (for staff) or the customer display (for customers).

Here's the full set.

The last month we have been working in stealth mode on the Web Point of Sale (POS) project so you may not be aware of what this is all about. Good things need to be shared and stealth is stupid, so let me give you an update on the latest exciting developments for retail.

What is Openbravo Web POS?

• Openbravo Web POS is intended for multi-store retail businesses. The solution will be modular, providing a full list of advanced functionality to cover all requirements needed from the point of sale, store management, to the central head quarters.
• Openbravo Web POS will have an agile, flow oriented, best of breed web user interface oriented to tablets and touch screen systems. The solution aims to provide a highly satisfying staff and customer experience but also needs to be easy to customize and personalize by business partners and end users.
• Openbravo Web POS is an enterprise level solution that is fully integrated with the ERP using one logical data model. It is also highly scalable and offers web services to expose the enterprise model to the outside world.
• Openbravo Web POS is an addition to the existing POS client. The choice of deployment options will be left to the business partners and customers.

What have we done so far?

• The architecture has been decided. Read details here.
• The main flows and functionality have been designed. Here´s a SlideShare presentation showing the latest iteration.
• Interactive mockups were built for both desktop and iPad. Download HTML Mockup (unpack zip and run in browser). Download iPad Mockup (you need an app called Presentation Link to run the iPad version).
• Usability tests were conducted on 12 users using the interactive mockup mentioned above.
• Based on the findings, we improved weaknesses of earlier versions along the way, resulting in the 8th iteration, which is considered mature. This means that we are now very confident this is going to work for our users.
• The visual design phase has started. Here's where colors, typography, layout and style are defined. Most POS software is butt ugly and this needs to change. I will share some art work in the next few days.

We're very excited about the Openbravo Web POS. Mind you, this is not your average POS system. This is a retail solution that combines a great web-based user experience with a solid enterprise architecture.

Yesterday we had a session with the Development Team on Re-introduction to JavaScript and Openbravo 3 Architecture.

Some of the topics covered in this talk:

• What happens when I login into Openbravo
• What’s a Component Provider or a Component
• What’s a Data Source
• Which are the JavaScript classes behind a Openbravo window
• When I need to compile or just restart Tomcat server

You can watch them online at:

• http://openbravo.adobeconnect.com/p80kovni69u/
• http://openbravo.adobeconnect.com/p9qym5viat5/

Enjoy!

As you may know we are iterating over several JavaScript frameworks to find the most appropriate for the mobile version of Openbravo 3.

As Salvador mentioned in the Open Discussions forum, Backbone.js + Twitter’s Bootstrap is a valid combination for a mobile application.

Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface …

On the other hand, Enyo

Enyo is an open source object-oriented JavaScript framework emphasizing encapsulation and modularity. Enyo contains everything you need to create a fast, scalable mobile or web application:

Built from the ground-up for mobile first – Enyo powers webOS, and was designed from the beginning to be fast and work great on mobile devices …

How easy is to create a plain product list using Backbone.js or Enyo? I wanted to give it a try. With a few lines of code I was able to make a REST call to Openbravo’s REST JSON Webservices and render a list of products.

Backbone.js

var Product = Backbone.Model.extend({});

  var ProductList = Backbone.Collection.extend({
    model: Product,
    url: '../../org.openbravo.service.datasource/Product',
    parse: function (response, error) {
      if (response && response.response) {
        return response.response.data;
      }
    }
  });

  var Products = new ProductList;

  var ProductsView = Backbone.View.extend({
    el: '#products',
    
    tag: 'ul',
    
    tpl: "<% _.each(models, function(product) { %> <li><%= product.attributes._identifier %></li> <% }); %>",
    
    initialize: function () {
      Products.bind('all', this.render, this);
      Products.fetch();
    },

    render: function (event, collection, error) {
      $(this.el).html('<ul>' + _.template(this.tpl, collection) + '</ul>');
      return this;
    }    
  });

  var App = new ProductsView;

Enyo

enyo.kind({
  name: 'ProductList',
  kind: enyo.Control,  
  components: [
      {name: 'btn', content: 'Load Products', ontap: 'loadProducts', tag:'button'},
      {name: 'list', tag: 'ul'}
  ],  
  loadProducts: function() {
      new enyo.Ajax({
        url: '../../org.openbravo.service.datasource/Product'
      })
      .go()
      .response(this, 'processResponse');
  },
  processResponse: function(inSender, inResponse) {
    var data = (inResponse && inResponse.response && inResponse.response.data), i;
    if(!data) {
      return;
    }
    for(i = 0; i < data.length; i++) {
      this.$.list.addChild(new enyo.Control({
        tag: 'li',
        content: data[i]._identifier
      }));
    }
    this.$.list.render();
  }
});
var products = new ProductList().renderInto(document.body);

I have packaged this code examples as a module. You can install it by cloning the repository and running smartbuild:

openbravo$ cd modules
openbravo/modules$ hg clone https://bitbucket.org/iperdomo/com.wordpress.katratxo.mobile.sample1
openbravo/modules$ cd ..
openbravo$ ant smartbuild -Dlocal=no

Note: openbravo is the root of your Openbravo sources

This examples doesn’t handle authentication, so in order to test them, first login into Openbravo and then visit the urls:

• /openbravo/web/com.wordpress.katratxo.mobile.sample1/backbone.html
• /openbravo/web/com.wordpress.katratxo.mobile.sample1/enyo.html

Conclusion

You can see that the Openbravo REST Web Services, provides a powerful layer for building alternative user interfaces for Openbravo.

We’ll keep iterating over the list of available JavaScript frameworks for Openbravo Mobile. If you have experience with Mobile Web Development, share your experience in the Open Discussions thread.

Openbravo 3 is a great product built on top of SmartClient library. SmartClient is a great framework that provides a set of UI components for building enterprise size, data driven applications, but it targets desktop browsers and is not well suited for mobile devices. You could make it work on a tablet device with some simplification of the UI you’re building, but when it comes to a smartphone, is way too heavy.

One of the key projects of Openbravo in 2012, is the support for mobile devices. In the last few weeks I’ve been doing some research on the available frameworks for mobile web development.

You can make a list of available HTML5 frameworks from developer community driven sites like Stack Overflow
or Hacker News:

• jQTouch
• jQuery Mobile
• Sencha Touch
• M-Project
• Titanium
• NimbleKit
• Wink Toolkit

We can complete the previous list with other libraries targeting mobile devices like:

• Jo
• LungoJS
• Dojo Mobile
• Kendo UI
• DHTMLX Touch
• Enyo

Splitting the list in two groups

The list of available frameworks can be divided in two groups based on their approach to solve the problem:

1. You need to generate HTML code and the library is just an abstraction on top of the DOM that helps you with the user interaction (gestures, tapping, etc)
2. You rely and “talk” JavaScript then the framework takes care of generating the necessary HTML code for building the UI component, plus helping with the user interaction (capturing events, etc)

From our experience in building Openbravo 3, the latter approach is preferred. It’s easier to write something like isc.Window.create({width: 600, height: 400}); than building the tree structure of DIVs for building a window, apply CSS styles and then test in the different supported browsers.

I went through the list of available frameworks. For example, jQuery Mobile takes the first approach. You need to create HTML tags and annotate them with some attributes like data-role in a list.

On the other hand, with Sencha Touch you “talk JavaScript” and the library takes care of building the UI component. Unfortunately Sencha Touch is released under GPLv3 license and is not compatible with Openbravo Public License (OBPL), so Sencha Touch is not an option.

For the same licensing reason Kendo UI and DHTMLX Touch discarded too.

Other libraries

There are other interesting libraries like Bakbone.js or Ember.js.

Backbone.js “gives structure to web applications” and is usually used with jQuery or Zepto, and Ember.js (previously SproutCore 2.0) aims to eliminate “boilerplate and provides a standard application architecture”. A comparison between the two libraries can be found on Backbone and Ember

Other Approaches

There are other attempts to use Google Web Toolkit combined with PhoneGap to build mobile applications. You can check the Webcast made by O’Reilly Creating Mobile Apps with GWT and PhoneGap.

Conclusion

We haven’t decided yet which framework we’ll use, but we prefer to use a library that will help us eliminating the need of generating HTML code.

We are still iterating over the available choices, but probably we’ll make a decision in a few weeks.

If you have experience in mobile web development and want to give us a hint, we’ll love to hear from you. Drop us a line in our Open Discussion forum thread.