Sketch to author crowd animations

My last year internship was a research project about crowd simulation. The idea was to not focus on simulation but on user control over the crowd. Some research has explored user control techniques that involve using a ‘brush tool’ (similar to a paint brush) or pre-labelling areas of the environment or using a sketch-based approach.

The solution developed is a sketch-based interface to author crowd animation. A user can sketch the boundaries of crowd formations and the crowd moves from one formation to another.

https://www.youtube.com/watch?v=j1bbHNOGFlA

The next step will be to introduce more patterns to fill the formation and add a path to follow in-between formations.

"My todo list everywhere" an example of GWT + AppEngine

Those days, I played with GWT and AppEngine (GWT is an easy way to write ajax application, and AppEngine is a host, datastore and set of tools for web applications). Their are great tools, and a lot of tutorials are available.

The downside for a new incomer is to find an example mixing a lot of features of each technology. But, don’t be afraid, here you will find a great example =0).

The web application is a very simple todo list manager. You login with your Google Account, and be redirected to your set of todos. You can add/delete todos. It’s simple but also enough complex to discover and use a lot of features of GWT and AppEngine.

What can you find in this example ?

How to serve a GWT application by a servlet generating the webpage and including the xxx.nocache.js

How to use Activity, ActivityManager and Place and how to mix them with GIN (Guice for GWT, which is a dependency injection framework)

How to use GWT RPC communications with the Action/Response design pattern.

How to inject RPC in and RPC out event to display a loading popup.

How to embedded JavaScript data while serving the GWT application webpage in order to reduce the number of server requests (embedded implies that you save a few requests to the server after page loading)

To be continued …

What can be improved ? (a lot)

** **1. Less server requests

• Inline CSS styleSheet
• Serialize user todos in the app webpage javascript (those data will be display after the login, so “why do we wait that the user fully load the page and request his todos ?” Look at what was done for UserAccountDTO on app main page and do the same for user todos)
• (Included in the previous: don’t send a “get todos” to the server each time the todo activity is displayed.)

1. Less work on the client side

• HeaderActivity is very simple at the moment and can be migrated into plain HTML.
• (Some sort algorithm and deletion strategy can be improved.) <- Not the first goal of this example

1. Better user experience

• Use GWT internationalization facilities
• Better feedback that only the loading popup. (ie: todo added)
• Smartphone dedicated interface (everything ready in the code, only need to write them)

What you must don’t look !!!

Please, don’t juge the CSS. I didn’t spend time on it, so it’s a bit messy and not well or not at all organized.

Where can I find this example ?

Application link: http://todo-list-everywhere.appspot.com/

Source code link: http://code.google.com/p/my-todo-list-everywhere/

MVC vs MVP – Part 2

#What is the major difference ?

In MVC, the biggest portion of code is shared between the Controller and the View. The controller contains the logic, and the View know how to render the model and listen model changes.

In MVP, the biggest portion of code is solely in the Presenter and the View is entirely passive. The presenter contains the whole logic, and the View doesn’t know what it’s displaying.

#What is the benefit of each approach ?

In MVC:

• All information displayed is manager by the view itself (When you need to translate your software, only view classes will be edited.)
• The controller don’t always need to push the new edited value of the model (push to view class).
• FYI: The model must be designed and finalized before the view

In MVP:

• The view is solely passive, you can easily replace the view by a stumb one in order to run unit tests. Such tests (with a stumb view) will have a better coverage than MVC approach
• As the view is passive and doesn’t contains any kind of logic, the view can be more easily tweaked without impacting the logic.
• FYI: The model can be designed and finalized after the view

#When to use MVC or MVP ?

This is a project specific question: sometime the framework used is designed for on approach, sometime you will use the other approach because you cannot rely on the View for your tests, etc…

Between MVC and MVP, the best approach is the approach that match your needs.

#An example of programme designed with both approach:

mvp example
mvc example

For MVC or MVP, the order of instantiation of the view, controller/presenter isn’t important. Try to focus on the communication between the 3 entities (model, view, controller/presenter).

MVC vs MVP - Part 1

MVC or MVP everyone  have heard those acronym at least once. But what they exactly stand for ?

MVC is Model View Controller and MVP is Model View Presenter. I can see some of you saying “what a scam” they changed one word and voilà. It’s a little more complex than this. Let’s start with some diagrams

As you can see, the communication between each entity isn’t identical. I will try to explain this difference.

MVC

The view

In the MVC design pattern, the view know the model and can display it.

    public class MyView {
        private Model model;

        private void populateView(Model model)
        {
            final String name = model.getName();
            this.label.setText(name);
        }
    }

The view listens the model an will be aware if it changes.

    public class MyView implements ModelListener{
        public void onModelChanged()
        {
            //Update the view with the new status of the model
        }
    }

The controller

The controller knows the view and listens event from it.

    public class MyController implements ViewListener {
        public void onButtonClicked()
        {
            final String name = view.getName();
            view.displayPopup(name);
        }
    }

The controller can modify the model without updating the view, because the view is a model listener.

    public class MyController implements ViewListener {
        public void onButtonClicked()
        {
            final String name = view.getName();
            model.setName(name);
        }
    }

MVP

The view

In the MVP design pattern, the view doesn’t know the model and receives basic orders to populate the interface (setLabelText, setTodayDate, but never read value from the model)

    public class MyView {
        public void setNameValue(String name)
        {
            this.label.setText(name);
        }
    }

The presenter

The presenter knows the view, populates the view and binds itself to interface listeners

    public class MyPresenter {
        private View view;
        private Model model;

        public void bind()
        {
            this.view.addButtonActionListener(new ActionListener() {
                @Override
               public void actionPerformed(ActionEvent event) {
                   this.view.setText("blabla");
               }
           });
        }

        public void populateView()
        {
            this.view.setName(model.getName());
            this.view.setButtonEnabled(true);
        }
    }

The presenter is the only entity to know the model and to listen it.

    public class MyPresenter implements ModelListener{
        private Model model;

        public void onModelChanged()
        {
            this.view.setName(model.getName());
        }
    }

To be continued…

A great book about search engine interfaces

I read a great online book about search engine interface: “Search engine user interfaces” by Marti A.

What I like is that the book is FREE, isn’t technic but gives you a new approach to interfaces (by interfaces, I mean every kind of interface: softwares, websites). You will discover some guidelines like “offer efficient and informative feedback”. Sometime, they seem very simple but they are very effective. The chapter dedicated to guidelines is the chapter 1, here is a quick overview :

• Keeping the interface simple
• …
• Offer efficient and informative feedback
• Balance user control with automated actions
• Reduce short-term memory usage
• Provide shortcuts
• Reduce errors
• Recognize the importance of small details
• Recognize the importance of aesthetic in design

To read the chapter 1 click here.