Big picture: graphical user interface

[W.P. McNeill]

This is a big picture suggestion, beyond the scope of the current project, but I want to get it down in writing for anyone who joins in the future.

The ELTK is necessary infrastructure work, so for the most part our effort is not going to be directed towards pretty user interface.  But in the long run this work will only matter if there is buy-in from linguists without an interest in computation, and that will only happen if we give them visual tools.  Even if we're not going to do the work now, it's worth thinking about how whatever we do write could be integrated with visual tools in the future.

For example, the SignListReader I'm working on now.  It takes a CSV file as input, so the natural graphical user interface is a spreadsheet program.  Should someone write a simple spreadsheet GUI in Python?  Should we find a way to interface with Microsoft Excel?  Should be leverage Google Docs tools?  We should have this in the back of our minds as we work.

--
W.P. McNeill
http://staff.washington.edu/billmcn/index.shtml
Sent from Seattle, WA, United States

[scott farrar]

Hi Bill

Good points. In fact, this was actually my plan. I was hoping that you and I could start thinking about this aspect of the project this qtr. if there's time. My main goal of having you on board is to help me get the underlying code-base right, but we may as well go ahead and start planning the next "phase". I'm currently in the process of recruiting Dwight van Tuyl (from LinguistiList, who was at the Buffalo meeting) to join the CLMA and work with me on the GUI and the other Web aspects of the code.

The idea is to have a set of cloud Google-like apps to do:

-search (current grant)
-dictionary editing and conversion (next grant)
-IGT editing
-something w. Steve's PHOIBLE (steve's grant)

I've played around w. Google Apps, but have decided to use Django (very similar to what Google uses anyway) which offers more flexibility as we control it all. I can talk about this in our next meeting btw.

Scott

[bambooforest]

I'm a bit weary of Django. What are your reasons over another platform, Scott. And if Dwight is going to be working on some of this stuff, he should probably weigh in, too. (I didn't look to see if he's on this list.)

Long live democracy. ;)

[Dwight VanTuyl]

The backend web framework we use doesn't matter too much I think. It just needs to act as an event handler between the client and the ELTK. Why are you weary of Django Steve? We could also use Pylons which seems to be fairly popular(http://pylonshq.com/). I'm not too familiar with either one though.

For the GUI side, I'd suggest looking at extjs.com. I've been using this javascript library for every project at the Linguist List now and have found it to be very useful for building GUI's for web applications. Another thing to look into are current technologies that allow a web application to be used offline. The two front-running choices being Adobe AIR and Google Gears. This wouldn't allow the user to utilize ELTK offline, but rather allow the user to enter in data using the same interface as if they were online into a local cache and then easily transmit their data to the ELTK web service when they have an online connection. Gmail works this way when you set it to offline mode and have installed Google Gears.

Dwight

[Robert Forkel]

>
> The idea is to have a set of cloud Google-like apps to do:
>
> -search (current grant)

what kind of search would this be? a crawler plus index (or triple
store and sparql endpoint) for GOLD documents on the web? if so, i'd
be interested in the details. in a project i'm working on, we plan
something similar - possibly with a more narrow proof-of-concept-like
scope.
regards,
robert

[W.P. McNeill]

I read a little about Django over the weekend. I don't know enough
about Python-compatible web backends to have an opinion, though I do
think when it is time to make pretty UI we should go for a web
application and not do any local machine hosted work. Web-based cloud
apps are the way the world is going at the moment, and it's just too
hard to make local UI's not look chintzy.

The more I think about this, the more I get convinced there's an
opportunity in here. If you tell a linguist, "Here's a web-hosted app
that lets you store and share your data online automatically," you've
got a shot at generating interest. Particularly if the website has an
example data set and some attractively formatted text and graphics.
But if you say, "I've got this great tool that lets you retype all
your data into an Excel spreadsheet in a slightly different format,
export it as a CSV file, then run a Python script that outputs the
same data in an XML format that contains GOLD URIs, isn't that
awesome!" forget about it.

The opportunity lies in the fact that cloud-based storage and sharing
is not built into Excel, the current tool of art. So we have a wedge
that allows us not to be competing directly with a Microsoft product,
which is what a locally hosted system (even one with a tie-in to an
online GOLD database) does now.

The infrastructure and GOLD interfaces are important stuff, in the
long run maybe the most important stuff. And in the interim we'll
need command-line tools. But the ontology will never be a selling
point. At least not at first. This is not a build-it-and-they-will-
come project. When it comes time to sell this to a broader linguist
audience, we should advertise it as a cloud-based archiving and
sharing app. The GOLD stuff is more like a stealth feature. But I
could see a website with one or two nice entry apps and a search
facility being compelling.

I think we have a shot at the adoption problem. A long shot, but a
shot.

On Aug 16, 9:45 pm, Dwight VanTuyl <dwi...@linguistlist.org> wrote:
> The backend web framework we use doesn't matter too much I think. It
> just needs to act as an event handler between the client and the ELTK.
> Why are you weary of Django Steve? We could also use Pylons which seems
> to be fairly popular(http://pylonshq.com/). I'm not too familiar with
> either one though.
>
> For the GUI side, I'd suggest looking at extjs.com. I've been using this
> javascript library for every project at the Linguist List now and have
> found it to be very useful for building GUI's for web applications.
> Another thing to look into are current technologies that allow a web
> application to be used offline. The two front-running choices being
> Adobe AIR and Google Gears. This wouldn't allow the user to utilize ELTK
> offline, but rather allow the user to enter in data using the same
> interface as if they were online into a local cache and then easily
> transmit their data to the ELTK web service when they have an online
> connection. Gmail works this way when you set it to offline mode and
> have installed Google Gears.
>
> Dwight
>
>
>
> bambooforest wrote:
> > I'm a bit weary of Django. What are your reasons over another
> > platform, Scott. And if Dwight is going to be working on some of this
> > stuff, he should probably weigh in, too. (I didn't look to see if he's
> > on this list.)
>
> > Long live democracy. ;)
>

> > On Sat, Aug 15, 2009 at 9:26 AM, scott farrar <sofar...@gmail.com
> > <mailto:sofar...@gmail.com>> wrote:
>
> >     Hi Bill
>
> >     Good points. In fact, this was actually my plan. I was hoping that
> >     you and I could start thinking about this aspect of the project
> >     this qtr. if there's time. My main goal of having you on board is
> >     to help me get the underlying code-base right, but we may as well
> >     go ahead and start planning the next "phase". I'm currently in the
> >     process of recruiting Dwight van Tuyl (from LinguistiList, who was
> >     at the Buffalo meeting) to join the CLMA and work with me on the
> >     GUI and the other Web aspects of the code.
>
> >     The idea is to have a set of cloud Google-like apps to do:
>
> >     -search (current grant)
> >     -dictionary editing and conversion (next grant)
> >     -IGT editing
> >     -something w. Steve's PHOIBLE (steve's grant)
>
> >     I've played around w. Google Apps, but have decided to use Django
> >     (very similar to what Google uses anyway) which offers more
> >     flexibility as we control it all. I can talk about this in our
> >     next meeting btw.
>
> >     Scott
>

> >     On Fri, Aug 14, 2009 at 12:51 PM, W.P. McNeill <bill...@gmail.com

[Dwight VanTuyl]

I agree that building a web GUI for entering various data structures
directly into ELTK is useful to linguistic researchers who are not
already using the cloud as their repository. But I would caution against
the idea that developing these interfaces are integral for users to buy
into using an ELTK web service. Developing a GUI for entering data, as
well as any graphical query interface for searching across data, should
be considered modular components apart from the main focus of ELTK. I
see ELTK as a service that consumes linguistic data of any form and
makes it interoperatble using GOLD. The strengths of this
interoperatbility and usefulness of ELTK as tool that enables this goal
will be seen when there is a large enough base of data that has been
transitioned to GOLD aware RDF. I think in order to prime the pump of
user acceptance, there needs to be some interaction between ELTK and
already established repositories of data. We currently have plans for
this interaction with Linguist List's LEGO, but are there others? I just
think that the amount of machine readable linguistic data that is
already out there is in greater quantities than what we hope could be
obtained through building a GUI. Also, that ELTK as a web service should
focus on having an interface, described by WSDL, in which any GUI, be it
for an existing project with its own repository or our own brand of web
GUI, can communicate with using web standards such as REST or SOAP.

[Robert Forkel]

i'd agree with dwight that the amount of data that's already there and
just has to be turned into GOLD is pretty big. from the projects i'm
involved with there's WALS [1], IDS [2] and a couple of others. All
this data is waiting to be put in the linkeddata cloud (which i'm
working on). and from my point of view - as a non-linguist programmer
- a couple of examples and best practices on how to encode typical
data (word lists, IGT, ...) in GOLD would be more help than a GUI.
i also think that having data resources available that you can just
pull in when working with ELTK will make the tool more attractive.
i'm also curious about how you envision people work with data in GOLD?
do you think sparql and querying the graph directly will work? for the
kinds of questions i'd have in mind (like 'give me all counterparts
for the meaning "tree" in this geographic region'), i think the GOLD
data model might be too detailed. are there experiences with the
queriability of GOLD?
regards,
robert

[1] http://wals.info/
[2] http://lingweb.eva.mpg.de/ids/

[scott farrar]

Hi Robert

what kind of search would this be? a crawler plus index (or triple
store and sparql endpoint) for GOLD documents on the web? if so, i'd
be interested in the details. in a project i'm working on, we plan
something similar - possibly with a more narrow proof-of-concept-like

Originally, I intended to create a simple interface to a triple store, with a sparql endpoint. The test data are RDF representations of ODIN data (http://purl.org/linguistics/odin).

But now, since I've started to develop the ELTK, I see real value in something a little more involved. All the sparql-driven interfaces I've seen are clunky, and lots of pull-down menus don't seem to help. That's why I think we need something a little different. I'm open to suggests and collaboration.

Scott

[scott farrar]

Dwight and Bill

Very good points, both of you. I definitely think now is the time to develop something like this. Our field's "toolbox" is painfully outdated. There's never been any tool that *most* linguists use, except maybe for Word/Excel, too generic for what we want. I just looked at samples on the extjs page---very impressive!

But Dwight's point is well taken. Not only do we need fancy GUIs and a trusted set of editing tools, but these tools should facilitate legacy data migration. The question is which to begin with? We need something to catch the attention of potential users. I see that being a tool for  "search and visualization of data". That data are LEGO's lexical data and ODIN's IGT data. Once we have that in place, then we can start (within the same framework) on expanding the editors and Excel converters.

Also not to be overlooked: we promised certain things in our grant proposals, so I'm partially driven by these goals, though there's a good deal of flexibility here, esp. in the upcoming Kawapanan grant.

Scott