Apr 30, 2010

Bed Time for the Click and Scroll Myths

by Rob Goris
In site or application design, it is recommended to use best practices, rules-of-thumb and proven principles. User experience specialists validate most of their ideas and designs using those. In case they can't find any, they mostly resort to usability testing, trying to prove that something works or not.

Over the years, some of the rules-of-thumb have seeped through to the broader audience and are now widely used and abused. Some classic examples are: "Flash is Bad", "Frames Suck", "People don’t scroll!” and the most obstinate of them all must be "I should be able to find everything on a site in just three-clicks!".

The first two claims at least can be defended with reasoning and by the simple fact that Jakob Nielsen´s words are not to be disputed. The claims that user don´t scroll and that every page must be reached within three clicks are myths. There is no scientific proof or sound reasoning behind them.

In the case of scrolling, some 15 years ago many first time web users had to get used to content being spread out over a larger vertical area that needed scrolling to be viewed. Now, in 2010, it is not hard to assume that people learned how to use a mouse. Obviously, for advertising, being above the fold makes sense as more people will see your ad when landing on the page (where else are they going to look?). In the context of user tasks, users are willing to scroll, although they say they don't. Even Jakob Nielsen succumbed in 1997 and wrote that scrolling is now allowed.

My favorite myth is the Three-Click-Rule. In countless discussions with clients, management and developers I have heard this "argument" being used. I confess that I even shamelessly used it against others when it served me well. I have always kept my mouth shut when The Myth was used against me when designing e-commerce sites because it always made sort of sense to me to get that 12-piece knife set in gift wrapping as soon as possible in the basket and checked out before the customer changes her mind. And even in this case research has shown that The Myth does not hold true. User Interface Engineering (UIE) conducted an analysis showing that there wasn't any more likelihood of a user quitting their purchase process after three clicks than after 12 clicks. In the same analysis we can find that user satisfaction does not suffer with more clicks either: Fewer clicks do not make more satisfied users.

So, user frustration and success rates in task completion do not depend on the number of clicks. Nor do they rely on not having to scroll. What really matters is that users can find what they are looking for, which depends on many factors such as flow, layout, interaction and visual design. If users find what they are looking for in a logical (and therefore effortlessly reproducible & memorizable) manner, both success rates in task-completion and user satisfaction will be higher.

Most - if not all - of the research on these topics was conducted on web sites rather than applications but I suspect little difference in its applicability. In the case of business applications, such as ERP software, we need to be a little bit more careful because of the factor productivity. Productivity is output per unit which in most cases can be captured as work per time unit. This is where speed comes in. In our case, the speed of operation of the user is very important. It depends on the response time of the system and the user interface. The first is a purely technical matter; the second depends on the GUI design. I believe that the number of clicks and the amount of scrolling has little impact on the user productivity as long as the user has easy access to all information that is needed for the task at hand and all steps in the task flow are logical, predictable and reversible. Also: providing defaults, offering validation, saving preferences and supporting different modes of seeking information boosts user´s productivity.

If we look at an example of creating a sales order: Most of the time spent executing this task is spent on finding documents and entering and validating field values, either for headers or lines and in grids or forms. The time spent on clicking and scrolling is negligible compared to that. Making sure the user finds the right documents, processes, forms and fields and making sure that she performs the process steps in the right order without making mistakes is much more important.

Another great productivity enhancer is using keyboard shortcuts. Here the same applies: the amount of key presses is not very important, the underlying logic is.

There is nothing negative to be said against trying to minimize the amount of mouse clicking or scrolling, it even helps designers rethink their solutions and simplify process steps. They just should not be used as a rule or best practice. Let´s put these click and scroll myths to bed and start focusing on good design.

Photo courtesy of Thad Zajdowicz



Apr 29, 2010

Openbravo ERP Ubuntu Lucid package available

by Juan Pablo Aroztegi

Ladies and gentlemen, fasten your seat belts. It’s here. Be ready for the new Cloud experience with Openbravo ERP and Ubuntu. For the long awaited Ubuntu release, codename Lucid Lynx 10.04, has been just released today! Two key words you should never forget:

  • LTS: this is a Long Term Support release. A new LTS version is released every 2 years and it gets longer support and more focus on security, stability and maintenance.
  • Cloud: first class cloud computing support in Amazon EC2 and Ubuntu Enterprise Cloud (UEC). It’s never been easier to work with your Openbravo ERP Ubuntu instance on the Cloud.

Fine, this sounds good. But how do I install it? First you need to get Ubuntu Lucid Lynx up and running. You can do this in mainly two ways:

  1. Install Ubuntu on a local machine: your own computer, a local server or a virtual machine.
  2. Run an instance on the Amazon EC2 cloud. Use the official AMIs. If it’s for a production server make sure you choose the EBS powered images (aka persistent storage).

And once this is done, install Openbravo ERP:

  1. Enable the Partner’s Repository:
  2. sudo add-apt-repository "deb http://archive.canonical.com/ubuntu lucid partner"
    sudo add-apt-repository "deb-src http://archive.canonical.com/ubuntu lucid partner"
    
  3. Install the openbravo-erp package:
  4. sudo apt-get update
    sudo apt-get install openbravo-erp
    

You can also install it using Synaptic or the Ubuntu Software Center:

Software Center: Openbravo ERP installation

For more details about the installation process you can check the complete intructions in the user’s manual.

This package is powered by PostgreSQL 8.4, OpenJDK 6, Tomcat 6 and the Apache HTTP Server 2.2.

It’s been a long way and with your help we have improved the stability and overall maturity of the Ubuntu + Openbravo ERP experience. We are excited with new delivery. Enjoy!


Tagged: Cloud computing, EC2, OpenJDK, Packaging, PostgreSQL, Releases, Ubuntu



Apr 29, 2010

The fix report

by Adrián Romero
In Openbravo we have a great tool for Openbravo ERP and Openbravo POS, the Openbravo Issue Tracking System. This tool is open to all partners and members of the community. Here you can log new issues, search for open issues, closed issues, monitor the evolution of issues, participate in the issues discussions, etc. Issue reporting is very important. A good issue report is great for Openbravo engineers because it helps to evaluate the issue, and makes it easier to keep track of open issues, verify and fix them. In our wiki we have a defined QA Assurance Process and a detailed Bug Reporting Guidelines that explains how to log a good issue report. I recommend to everybody that works with Openbravo ERP and POS to have a look at these documents.

But if the issue report is very important to understand and fix the issue. The fix report is also very important too. The fix report is no more than a note added to the issue report by the engineer that explains in detail what has been done to fix the issue. The fix report makes it easier for the QA team to verify the correctness of a fix because when closing an issue they have to check that the issue is properly fixed and the modifications in the sources are correct. And it is important too for users, implementers and administrators of Openbravo ERP when they have to apply a fix or upgrade a live implementation. Changes in live Openbravo ERP environments are critical and we must provide to administrators the maximum confidence in the fixes provided. Apart from fixing the issue, the rest of the existing standard or custom functionality must continue working the same way. Usually regression issues introduced by an upgrade or a fix are several times worse than the issues fixed.

In order to improve the fix report we are introducing in the Support Team new guidelines to follow after a fix has been done and pushed to the Openbravo ERP or POS sources repository. The sections that this fix report must include are the following:
  • Testing of the issue: Describes the steps to follow in Openbravo ERP or POS to verify that the issue has been fixed and the results obtained. It is usually very similar to the steps to reproduce but changing the results obtained.
  • Explanation of the changeset that fixes the issue: High level explanation of the modifications in the sources. It should explain what has been modified in each file and why. For example when adding two new fields to a report, it has to be explained that the SQL query of the report has been modified to get the field values, the jasper report template has been modified to display the fields and also that has been included two new records in the AD_TEXTINTERFACES table to translate the report labels.
  • Other areas affected by the changeset: Usually the changes done to fix an issue affects source code that is used in several parts of the application. In this section it has to be listed all the functional areas related with the change done and how are affected, and what are the changes in the behaviour if any. This section is very important because it helps to explore if any regression can appear with this fix. For example, when modifying the PL/SQL function C_INVOICE_POST, it has to be explained that all functions and windows that create and post invoices can be affected. It also has to be explained what are the type of invoices that can be affected by the issue, whether the invoices affected by this fix depends on the document type of the invoice or the payment terms...
You have a few examples of fix reports in the following issues: 12959, 12474, 12628 and 12856. And if you have suggestions to improve more the fix report we are currently implementing, we will be glad to hear them.



Apr 26, 2010

Improvements in our Selenium code

by Openbravo QA Team

One of our team members has made a blog post about the recent changes in our test code. We hope this new structure will make coding easier.




Apr 26, 2010

XML REST Web Services testing added to our Continuous Integration Framework

by Gorka Gil

Openbravo ERP REST consists of a framework offering security and exception services and a data access REST web service implementation. The data access (DAL) REST web services provide a CRUD-like web service so that external applications can retrieve, update, create and delete business objects through standard HTTP requests.

From now on we’ll be testing these web services in our build farm: http://builds.openbravo.com/job/erp_devel_int-webservice-check.

This test will check that the XML Rest Web Services work as expected, and that its functionalities are not broken by any commit.

More information about XML Rest Web services: http://wiki.openbravo.com/wiki/ERP/2.50/Developers_Guide/Concepts/XML_REST_Web_Services.




Apr 22, 2010

Web 2.0 for software practitioners

by Paolo Juvara
Openbravo founder Nicolás Serrano and José Manuel Torres just published a fascinating article on software engineering best practices leveraging web 2.0 technologies, using Openbravo as a case study.

The article is available on Computing Now, the portal of the IEEE Computer Society. It will be featured for a month on portal front page.

You can also access the article directly at this URL: http://tinyurl.com/2fl9p5j



Apr 22, 2010

Openbravo Forge achieves growth milestone: 10k Developers

by John Fandl

I just noticed that Openbravo Forge, the collaborative development environment from Openbravo, has reached the 10 thousand developer mark! When I last blogged about it in August 2009, Openbravo Forge had 6997 developers and 139 projects. Now we are at 10000 developers, working together on over 300 ERP-related projects!

This steady growth demonstrates what an open source community can do when a best-in-class project like Openbravo ERP is paired with a robust collaboration tool like Openbravo Forge.

Note that I am using the term "developer" in a general sense. Developing world class web-based ERP solutions for SMB requires a wide range of talent. So in addition to ERP application developers, Openbravo Forge users include ERP functional experts, System Architects, QA analysts, User Experience experts, and people involved in documentation, language translation, localization, and more. If you have an interest in ERP, check out Openbravo Forge to see what all of the excitement is about! Hint: it may have a little bit to do with collaboration and innovation... :)



Apr 20, 2010

Selenium automation: improvements in test package hirarchies and naming conventions

by Leo Arias

Hello dear Internet. My name is Leo Arias and this is my first post for the Openbravo Planet.

I work with the QA team helping the rest of developers to build high-quality software.

I spend most of the time maintaining the repository for automated testing. Pablo Lujan, also part of the QA team, recently presented a webinar with more details of the things we have done; you can find the recorded session here.

Recently we have been polishing the automation process in order to make it easier to code new integration tests for the ERP. This post will briefly explain the last changes in the packages hierarchy and the convention we are using to name tests. If you are interested in the automation of your Openbravo installations or the modules you develop this might be useful.

The package hierarchies

We like packages a lot and we are not afraid to use them :)

The main packages used in the automation of an ERP test are GUI, testscripts and testsuites. In order to create a new test case it's highly probable that you will have to touch only classes in this packages, because the rest are maintained by the QA team.

  • GUI (com.openbravo.test.integration.erp.gui): this package contains the definitions of ERP GUI elements (textfields, checkboxes, lables, etc.) and functions that perform actions with those elements receiving parameters from test scripts (create a new record, edit a record, process and order, etc.).
    The classes in this package inherit from the Window or PopUp classes, where common functions and attributes were previously defined; so here you add only the things that are specific to the screen you are automating.
    And they are stored following the Openbravo ERP Menu hierarchy, so we have sub-packages for the screens that are accessed through the General Setup menu item, the Master Data Management menu item, and all the rest.
  • testscripts (com.openbravo.test.integration.erp.testscripts): this type of classes specify the actions that have to be done on one or more windows in order to complete a test. This includes the steps, the verifications and the assertions that will tell if a test succeeded or failed.
    So basically this classes are a sequence of instantiations of GUI windows and calling of functions of those windows passing variables as parameters.
    And the hierarchy here also follows the Openbravo ERP Menu hierarchy. But, as there may be test scripts that perform actions on more than one menu item, they should be stored under the package named after the menu item where the most important action is executed.
  • testsuites (com.openbravo.test.integration.erp.testsuites): On this package we store test suites and the scenarios with actual parameters. Test suites are just classes that group scenarios. And scenarios are classes with the values that will be passed as parameters to testscripts in order to perform an actual test.
    This package follows the hierarchy of testlink because before automating a test it should be documented there.

In addition to that, we have modules package (com.openbravo.test.integration.erp.modules), where tests for Openbravo modules are stored.
So, if you are automating tests for Initial Data Load module for example, you should store them in com.openbravo.test.integration.erp.modules.initialdataload. And that package will have inside the same three packages previously explained, but for the gui elements, scripts and suites that are specific to the module.

Everything related to the packages of the repository is fully explained in the wiki.

Naming convention for test identifiers

We used to have a lot of problems with the identifiers of tests.
We wanted them to be unique and to follow the order of the suite they belong to. Problems came with the frequent task of adding new tests to a suite, because we used to number them with adjacent integers. So, if we had tests 1 and 2, and we required to add a new one between them there wasn't a straightforward way to keep the numbering sequence.

The naming convention we are using now starts by defining a three letter identifier for the suite. For example, we have ADM for Administration master data suite.
Then, the tests that form part of that suite will be identified by the three letters of the suite plus four digits. But the four digits will be a sequence of numbers from ten to ten. Thus, the first test of a suite would be XXX0010 and the second by XXX0020.

This way it would be easy to add a test in the middle of those, identified by XXX0015. And every time that a test suites gets to a stable phase, the tests will be renumbered to start again with a distance of 10.

This is explained with more detail in the wiki.

I'll continue posting things related to QA @ openbravo, tagging them with the Openbravo taxonomy term. Your comments and suggestions are appreciated, as always.



Apr 14, 2010

Continued growth of Openbravo Exchange

by John Fandl
We are pleased to announce that our friends from Datafashion  have just published a new developer-oriented module called the Interceptor Filter.  This module, which appears in Openbravo Exchange's growing Tools section, provides an easy way to intercept a user command, and attach custom logic to it without changing the core source code.

In related Openbravo Exchange news, the philosophy at Openbravo is to grow the Exchange organically and at high quality from the very beginning.  We want Openbravo Exchange to be a place that people can go to with confidence to find high quality, valuable extensions modules that they can easily install and combine to meet their unique needs.  To ensure that all Exchange modules install and uninstall correctly as we deliver monthly maintenance packs, we are testing all of them on a continuous integration basis per this defined process, which uses the Selenium toolset described in this recent recorded webinar.

So, if you don't find what you are looking for in Openbravo ERP, please remember to check out Openbravo Exchange.  New native Openbravo modules are being added all the time, and we are working hard to apply the latest technology and best-in-class processes to help assure high quality.



Apr 13, 2010

Selenium webinar recorded session

by Openbravo QA Team

As we announced last week, we held a webinar showing our vision of Selenium automation and Openbravo ERP.

The session was recorded, so if you want to take a look, it is available here.

Enjoy it!