[ome-devel] Shoola-back-end consistency issues

[Chris Allan]

On Wed, Jul 06, 2005 at 05:12:16PM -0400, Ilya Goldberg wrote:
> 
> On Jul 6, 2005, at 4:06 PM, Chris Allan wrote:
> >
> >I'd really like us to think about ourselves a little bit for once.
> >Helping out others who activly decide to do their own thing (code in
> >VB.NET using SQL# or access the DB directly using JDBC/ODBC/DBI, etc.)
> >is one problem, helping *ourselves* is another.
> 
> I agree that we should help ourselves first, and one of the ways we can 
> do that is to use other people's tools instead of developing our own.  
> That includes not just technologies that we base our tools on but 
> actual end-user tools already out there.  Sadly, these include 
> VBA/Excel for example.  One of our users has in fact requested help 
> with that very thing (one of your users, technically speaking).  The 
> fact of the matter is that if you want some tables and charts with some 
> data from OME, the quickest way to accomplish that is to connect OME to 
> Excel - not by writing our own graphing/charting tool.  And the 
> quickest way to connect Excel to OME is probably with some VBA thing.  
> And the simplest way to update the information on that spreadsheet?  
> With an update button.  End of story.
> 
> >If a third-party decides to actively choose to circumvent our attempts
> >to make their job of handling notification easier, so be it, there's
> >nothing we can do to help them if they choose that road.
> >
> >Focusing on what we need for Shoola and possibly extended to Visbio and
> >some events for the web interface to pickup on page loads is what I
> >believe we need to do here. This topic did not come up from some random
> >outsider, it came up from real users using *our* clients to connect to
> >*our server. Lets deal with those requirements.
> 
> I'm all for simplicity.  Simplicity is update buttons.  The user knows 
> when they need to be synchronized, and when they don't - its the user's 
> decision.  Doing stuff "automatically, behind the scenes" is great when 
> it doesn't interfere with the user's work.  This type of stuff drives 
> me absolutely batty when using MS products.  Changing what I'm looking 
> at and what I'm doing without my say-so.  Same for web sites that 
> auto-reload.  What makes them think I want an auto-reload?  I have the 
> reload button right here and I did not press it, so leave my computer 
> and my work alone, and stop distracting me!
> 
> Updating/notification systems can be nifty and fun, but they are not 
> used extensively in the real world even in cases where they would 
> appear to be beneficial.  First because they introduce a lot of 
> complication, and second because they circumvent user action and 
> second-guess user intent.
> 
> Here is a good example of dealing with consistency when editing the 
> same file with multiple editors:  I have a file open in BBEdit, but I 
> forget about that and edit it in vi from the terminal too, and save my 
> changes in vi.  What happens when I change focus to BBedit's window of 
> that file?
> If BBEdit's window is not dirty (no unsaved changes), it automatically 
> updates the file (when I change focus to that window, not when I save 
> the file in vi - i.e. polling).  I would prefer that it warned me what 
> it was about to do and allowed me to keep the BBEdit window as it was, 
> resulting in a dirty window, but with contents previous to the vi edit.
> If BBEdit's window was dirty, it warns me that the file was changed, 
> but not reloaded because it had unsaved changes.  I would prefer a 
> choice here as well, with the default being to keep the dirty window as 
> is.
> 
> If we reverse the roles of vi and BBedit, then vi only warns me when I 
> try to over-write a file that changed since its been read.  If I modify 
> the file in BBEdit and re-focus on the terminal, I have no indication 
> that the file I'm working on was changed by another program until I try 
> to save it.
> 
> Either way is fine really, because I'm given a choice what to do or a 
> warning of what happened, and I'm not distracted by windows changing 
> their contents in the background.  There are opportunities for me to 
> back out because my work is not changed without my consent.  Now, go 
> and type HTTP in all caps in MS Word and see what happens.  
> Auto-updating can really suck.

And if you did this with GEdit and GVim you'd have notification in GVim
the second you focused on that Window telling you the file had changed.
In fact, you can turn on such notification in Vim as well.

We're not developing a word processor and we're not Microsoft. Ever
looked at your Finder Ilya? It doesn't have update buttons. That's
because if you go to the terminal and type "touch file" and you've got
that Window open Finder gets notification of a change in that folder and
updates the display. That's what we should be striving to accomplish,
not auto-update for your spelling mistakes.

You are the Mac lover right? Microsoft GUI concepts and HCI are horrible
right? Should we resort to Microsoft-esque "Press F5 to Refresh" or
would you like the nice clean notification API and proper
synchronization?

> 
> -I
> 
> 
> >
> >Ciao.
> >
> >-Chris
> >
> 

Ciao.

-Chris