Two hours: Conclusion

As I mentioned in the first of these three posts, although David Lago was our point of contact in setting up this meeting, he was ultimately unable to make it.  I have no illusions as to my lack of understanding regarding the actual task of programming.  I am not the “tech guy” of our team.  I am what Michael Nelson has dubbed a “technology generalist”.  What this means is that I know just enough to be dangerous.  I thought about the possibility that in my attempt to explain and demonstrate what we are working on I would be bombarded with questions.  Questions are nothing new mind you, I field them all the time regarding ideabreaker.  However, I am not normally answering questions posed by individuals with PhDs in various branches of computer science.  That is David’s area of expertise.  He has all of the fancy letters behind his name and pretty pieces of paper on the wall.  Still, I was adamant about capitalizing on this opportunity as it had presented itself.  I started by showing some of our proof of concept materials and followed up with letting Vassil be the first person to see our still in progress prototype.

My reservations could not have been less warranted.  Of course Dr. Roussev and I  discussed the finer points of our technology and approach and collaborative practices in general, but I never at any point felt out-classed.  Vassil has that ability to break down complex materials into digestible pieces.  Aside from being a hallmark of a great teacher, it demonstrates much more when outside of the class room.  I will discuss this as a business dynamic in a future post.   In this post I will kill the last two birds with one stone by sharing our discussion on collaborative practices in software and Dr. Roussev’s thoughts on ideabreaker specifically as a product and a platform.  Much of what was put forth is already under consideration, but there were still plenty of eye opening material that I had not previously considered.

Roussev on ideabreaker.com:

Collaboration:

1.  Realtime must be mastered now.  Make it a priority because everything else is a cakewalk.  Careers are made simply on the topic of effective concurrency.

2.  Subtlety in team awareness [ color, icon, shape, transparency, simplicity ] is a difficult art  A mechanism for identity must exist.

3.  Users updating the workspace must be priority in collab development.  Otherwise: ping–>delay–>breakdown

4.  Looking beyond “realtime”:  You must decide between Asynchronous, Synchronous or Hybrid.  Each has its own unique problems, benefits and tradeoffs.

5.  Looking beyond “realtime” even further, identical or divergent environment?  How do you share?  How do you sync?

6.  Read Carl Gutwin.

7.  Reinterpret collaborative visualizations.  Translate human protocol to create intuitive environments.  How can you track the movements of team members on your screen in an effective but non intrusive way. (remote pointers and other visual tools, etc.)

8.  Merging data in a collaborative environment is a difficult science.  Explore techniques to “lock users” out and prevent simulatneous manipulation of the environment and the data.   This will be the toughest nut to crack.

Why is no one doing this?!

1.  No one is doing this because it has already be done.  10 years ago it was done, but the horsepower wasn’t there to do it effectively and the users weren’t there to take advantage of it.  People were not ready.   Remember timing.

2.  Research runs 20 years ahead of the commercial schedule, once the research is able to be commercialized it is done with academia.  It doesn’t belong here anymore.

3.  Everyone is doing something collaborative, look around.  But noone is doing it very well and noone has figured out how to make money with it.  Maybe you are different.  Maybe you will make the money.

4.  History doesn’t repeat itself, it just rhymes.

5.  Did I mention timing?

ideabreaker.com

1.  There are a tremendous numbers of opportunities within this platform, be careful not to chase them.  You cannot exploit them all effectively.  Focus cannot be overemphasized.

2.  Visual applications have been and are the future.  Software has been steadily marching in the direction that ideabreaker has decided to go.

3.  Your approach (object oriented data manipulation) is novel and necessary.  Tabbed has its place in high level organizational, and tables are necessary to view the actual data in a native environment and in a cogent fashion.

4.  People desire to interact in an environment that mimics on some level what they interact with outside of the PC.  This is critical to success.

5.  The programs that we built were what people today call “widgets”  These widgets were deployed to great effect in what was essentially a whiteboard environment.  What you have here is structured and ultimately more useful”

Wow.

Two hours continued. . .

As promised in my last post here is part 2 of my conversation with Dr. Vassil Roussev from the University of New Orleans.  These thoughts are listed in no particular order, but are grouped by topic.  Yesterday I posted some of Dr. Roussev’s thoughts on UI design.  In this post we are going to move into application development.  Feel free to take notes.  I sure did.

Dr. Roussev on Development:

1.  There are a tremendous numbers of opportunities within your platform, be careful not to chase them. You cannot exploit them all effectively. Focus cannot be overemphasized.

2.  Reinventing is not a bad thing. Succesful technologies are continually reinvented until their time comes.  The time must come. Technologies are reinvented until their time appears.

3.  Bill Gates never actually created anything. He just made exceptional packaging for existing technologies. Culmination is lucrative.

4.  Simple things just tend to work well.  You will do well to remember this.

5.  Did I mention Focus?

6.  There is a huge difference between playing and working.  Resist the urge to create a toy.  Again, remember Clippy.

7.  Every action, function, and feature must be necessary and have a visual metaphor.  Everything.  This cannot be overstated.

8.  Creative resources are necessary to successful development, but you can’t take your eye off of them for a second. Keep track of their movements.

9.  Let users drive your development and feature set to an extent. They will ask for what is important over and over and over. Not everyone is right, but be sure to listen for the ones who are.

10.  Be humble. Be confident but be humble.  Pride precedes dissaster.

Next:  Dr. Roussev on ideabreaker

Two hours with Dr. Vassil Roussev

David Lago is a 3rd degree blackbelt in Google-Fu. I really have no idea how he is able to find the information that he comes up with on a nearly constant basis.  Last week for example, he began feeding me a new line of papers, publications and research centering around collaborative software systems.  I stay very much on top of emerging trends in collaborative applications and groupware, but I must confess that I rarely delve into the type of information and data that academia has produced and is currently producing.  The one common denominator in the majority of the research that David had provided me with was a name.  Vassil Roussev.  As is often the case with these documents and slides, you have to work pretty hard to get your hands on them all.  As an aside, Dr. Roussev has a new site that is being put together as we speak, so check here from time to time.  I will also be attepting to consolidate his work on collaborative systems and software, but in the mean time you can find 4 of his papers here for sure.

With a little additional digging, David discovered that Dr. Roussev is currently a professor at the University of New Orleans, a stones throw away!  Given the nature of our company, our mission, and our forthcoming platform, we were stoked at the possibility of showing Dr. Roussev what we are working on.  Fortunately, after a bit or correspondence, Dr. Roussev agreed to sit down with us.  Unfortunately, David couldn’t make it.  Boy did he miss out   I was intent on not consuming too much of the Doctors time and I had a clear cut agenda.  3 questions.  Nothing more, nothing less.  Dr. Roussev was kind enough to answer my 3 questions, and then provide me with nearly 2 hours of unabated honesty in the realm of collaboration, software development, and a litany of other areas in straight stream of consciousness style.

I will devote the next few posts to sharing some of this insight.  Granted, some of these things may seem obvious,  others are very insightful, and others raise more questions than they answer.  This is in the first person as I heard it.  I have broken my notes down into some loose sections.  One of the areas that we discussed was user interface design and I think that I will start there.

Roussev on UI design:

1.  Human beings like to use something pretty. There are a large number of people that will not use an app strictly on the basis that they do not find it attractive.   Keep it sexy, but keep it simple.

2.  Eye candy IS important, but it is a fine line. Be careful not to overdo it.  Remember!  Simple things just tend to work well.

2.  Everything that the user sees must have a metaphor. Every action and visual effect needs a reason.

3.  Successful UI is never an accident. Never.

4.  Do not incorporate visual effects because you can. You will be cute for about 5 minutes. Then you will be hated. Think Clippy.

4.  Everything makes sense now while it is small. How do yo display the information when this thing gets huge?  This is the challenge.  Even mid-sized enterprise will result in huge.  Solve this when it is small or you will never be able to.

5.  Think about how you organize your stuff on your desktop.  Ask around, you will uncover both innovation and consensus.  Leverage this data to create filtering options for your users data.

6.  Piggyback what works now. An Icon with mouseover preview may be more than enough. Whatever you do, don’t be microsoft office 07.

7.  Resist going for the wow factor.  Cool wears off rather quickly. Cool is hollow.

8.  Did I mention keep it simple?

Next:  Application Development

Paul Graham is always Right.

Ok, noone is right ALL of the time, but there have been a precious few things that Mr. Graham has ever said that I have disagreed with, and even less things that didn’t benefit me as a person and entrepreneur.  In fairness, Mr. Graham’s “Fundraising Survival Guide” hit my box thanks to Ben Yoskovitz and the Instigator Blog. Ben is a genious in his own rite, but today we are talking about Paul Graham.

This particular essay is an instant source of equipping (if that makes sense) from the man who has taken a hard look at literally dozens of early, nasty, seed stage companies via Y-Combinator.  Mr Graham offers a uniquely human perspective on the process in part because he is one of the few individuals that has been on both ends of the spectrum.  Entrepreneur and Investor.  By the way, he has done each very well to this point.
Brilliant stuff.

Please do yourself a favor and check it out here.