Well it is with a mixture of sadness and excitement that I had my last day at Sabre this past Friday. Sadness, because I leave behind many friends and colleagues that I greatly respect. Excitement because of the opportunities ahead.
As I told those at my farewell party, I have had an absolute blast working there over the last 3 years. It has been challenging and rewarding working to establish a user experience team as part of the normal process within Sabre. I have been fortunate to have had great folks around me. And the really good news is that the team is well positioned to continue the momentum and do greater things with the new leadership coming into that team.
My new challenge is far from Texas where Sabre is based and where I have lived most of my life. I am joining the Yahoo Platform User Experience team (in Sunnyvale, CA). I have the interesting title of Designer/Ajax Evangelist and am looking forward to some really exciting work in the days ahead.
So what was it that got me interested in moving my family across the country, entering the crazy CA real estate market and leave an incredible job at Sabre?
It really came down to a strong gut feeling. First, the job pulls from so many things I have done in the past yet reaches into a number of unknown challenges. Second, I was amazed by the team of folks involved. One of the things I look for when creating a team or joining a team is the incredible mix of passion + brilliance + humility. That is not an easy balance to strike. The secret is to realize that the ideas are a team effort and the competition is outside the organization. I am very excited about what Yahoo is doing and will be doing in the future and am thankful for the opportunity to make a contribution there.
As for Rico, the effort is growing. Darren is being given a full-time role within Sabre to work on Rico. I hopefully (given time constraints of a new job) will continue to play an important role in the Rico project. Richard Cowin will continue his role as co-collaborator with Darren. Jacques Morel is also from Sabre and has recently joined the effort. Others are starting to join as contributors and there are some exciting talks happening around ways to expand the Rico effort.
My thanks and appreciation goes to David Endicott, VP Development Sabre Airline Solutions. He is an awesome guy to work for! And thanks to Brad Jensen my former VP who brought me to Sabre with his passion for usability.
Sunday, July 17, 2005
Sunday, July 10, 2005
Thin Ajax Clients - Model-View-Controller
Ok, I normally try to post just on the design side of things. But as you can tell I wear two hats: Technology and Design. This blog is on the technology side of things.
With the introduction of the LiveGrid behavior on our openrico.org site I have received a lot of good questions about how to do things like sorting, filtering, selection, editing, column re-ordering, searching, deleting, creating, etc.
In each case, the question is essentially the same. How do I sort the records since they are not in the client? Or how do I select all when I have only 10 records in the client?
The answer lies in one guiding principle: Keep as much data and logic on the server as possible and access it just in time.
We are strong believers in the software design pattern called Model-View-Controller. Essentially keep the model (data, business logic, domain objects) separate from the View (presentation, page, screen, forms) and let the Controller (events, submits, requests, interactions) drive pulling information (Model) to be presented (View) only as needed.
This results in a very thin client with little logic to maintain (read: avoid duplication on the client) and a smaller memory footprint on the client as well as avoiding having JavaScript do heavy lifting.
Lets take an example: Sorting. With the LiveGrid I have a few records in the client at any given time. If I want to sort then I would issue an Ajax request (Controller) to sort the data (Model) on the server. The response would be a small slice of the data (sorted) that gets shown in the table (View).
By pushing logic and data onto the server, we can implement a typical model-view-controller architecture that creates a clean separation of concerns and makes for a nice thin client.
We will open up API on the LiveGrid shortly that will make it easier to perform each of these type of functions.
With the introduction of the LiveGrid behavior on our openrico.org site I have received a lot of good questions about how to do things like sorting, filtering, selection, editing, column re-ordering, searching, deleting, creating, etc.
In each case, the question is essentially the same. How do I sort the records since they are not in the client? Or how do I select all when I have only 10 records in the client?
The answer lies in one guiding principle: Keep as much data and logic on the server as possible and access it just in time.
We are strong believers in the software design pattern called Model-View-Controller. Essentially keep the model (data, business logic, domain objects) separate from the View (presentation, page, screen, forms) and let the Controller (events, submits, requests, interactions) drive pulling information (Model) to be presented (View) only as needed.
This results in a very thin client with little logic to maintain (read: avoid duplication on the client) and a smaller memory footprint on the client as well as avoiding having JavaScript do heavy lifting.
Lets take an example: Sorting. With the LiveGrid I have a few records in the client at any given time. If I want to sort then I would issue an Ajax request (Controller) to sort the data (Model) on the server. The response would be a small slice of the data (sorted) that gets shown in the table (View).
Another example: Selection. Let's say I want to select all records. I hit some Select All link (like in gmail) and this issues an Ajax request to select all records (Controller). On the server some index list (Model) is updated to record that all rows are selected. The response comes back with the same rows being displayed (View) in the table-- except that the checkbox that is on each row gets checked based on a value set for the first (assume checkbox is first column) column of data.
By pushing logic and data onto the server, we can implement a typical model-view-controller architecture that creates a clean separation of concerns and makes for a nice thin client.
We will open up API on the LiveGrid shortly that will make it easier to perform each of these type of functions.
Sunday, July 03, 2005
Why is Sabre Supporting Rico as OpenSource?
I've been asked this question on numerous occassions. Here is my take on why it has happened.
1) Sabre Airline Solutions invested significantly in a set of standard core technology platforms built on open source technology (Java Swing, JSP/Struts, JDO, Hibernate, Spring, J2EE technologies, etc.). This rich experience with open source has created a desire among those involved to share back with the community.
2) During this investment phase a number of open-source friendly folks were hired and moved into influential positions
3) We understood that whatever innovations we had arrived at, others were probably at the same stage or would shortly be there. Why not put our stuff out and let it be a part of the early wave (for Ajax & rich internet applications) and perhaps influence how things shape up in the world. of the web Sabre has a history of innovations and so it fit with this thinking.
4) We understand that we are not really in the business of building frameworks. If we get our frameworks out to the larger community then they will only get better.
5) Those of us involved are pretty passionate folks that really get excited about innovation!
6) We have the right people at executive level that are willing to think outside the box about our how some of our software gets developed.
7) Its just great publicity.
I have been extremely pleased during my last three years at Sabre. I have had tremendous support in every endeavor I have launched. This support has been at the executive level, at the product marketing level and at the development level. I think things were just ripe for Sabre to do something like this.
Anyway that's my view on it.
1) Sabre Airline Solutions invested significantly in a set of standard core technology platforms built on open source technology (Java Swing, JSP/Struts, JDO, Hibernate, Spring, J2EE technologies, etc.). This rich experience with open source has created a desire among those involved to share back with the community.
2) During this investment phase a number of open-source friendly folks were hired and moved into influential positions
3) We understood that whatever innovations we had arrived at, others were probably at the same stage or would shortly be there. Why not put our stuff out and let it be a part of the early wave (for Ajax & rich internet applications) and perhaps influence how things shape up in the world. of the web Sabre has a history of innovations and so it fit with this thinking.
4) We understand that we are not really in the business of building frameworks. If we get our frameworks out to the larger community then they will only get better.
5) Those of us involved are pretty passionate folks that really get excited about innovation!
6) We have the right people at executive level that are willing to think outside the box about our how some of our software gets developed.
7) Its just great publicity.
I have been extremely pleased during my last three years at Sabre. I have had tremendous support in every endeavor I have launched. This support has been at the executive level, at the product marketing level and at the development level. I think things were just ripe for Sabre to do something like this.
Anyway that's my view on it.
Subscribe to:
Posts (Atom)