Javascript in OI WAS [gcd-main] Deleted and re-adding issues and series

[Andres Jimenez]

2011/3/13 Jochen Garcke <gcd...@garcke.de>:
> But some code for
> selection will be there when the reprint links - finally - will be
> introduced to production later this year. It probably won't be nice and
> fancy (as in no JavaScript), but useable.

What was the reasoning for not using JS in the OI for this purpose?

I thought the regular webpage was prefered without it, but it was
assumed JS would be unavoidable in the OI.

Cheers,

--
Andres Jimenez

GPG : http://www.andresin.com/gpg/gand...@gmail.com.asc

[Jochen Garcke]

Am 13.03.2011 12:08, schrieb Andres Jimenez:
> 2011/3/13 Jochen Garcke <gcd...@garcke.de>:
>> But some code for
>> selection will be there when the reprint links - finally - will be
>> introduced to production later this year. It probably won't be nice and
>> fancy (as in no JavaScript), but useable.
>
>
> What was the reasoning for not using JS in the OI for this purpose?

Lack of JS knowledge on my part and neither intention nor time nor
interest to learn it at this stage.

> I thought the regular webpage was prefered without it, but it was
> assumed JS would be unavoidable in the OI.

Sure. We want JS in the OI. But somebody would need to do it.

Jochen

[Andres Jimenez]

I am no JS expert at all, but I have used it in the past and would
have no trouble writing a few functions.

What is needed?

Andrés

2011/3/13 Jochen Garcke <gcd...@garcke.de>:

> --
> GCD-Tech mailing list - gcd-...@googlegroups.com
> To unsubscribe send email to gcd-tech+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/gcd-tech

[Henry Andrews]

We should pick a library to use- the most popular in Django-land last I checked
(and one of the most popular overall) is jQuery. This will help us with
cross-browser compatibility, although it won't magically solve all of those
problems.

We also need to be careful about how we add it. The correct way to add
JavaScript (based on my experience with another web app over the past three
years, learned the hard way) is to keep the JavaScript in files separate from
the HTML template files. Link in an external .js that initializes things. This
mostly means it should look for HTML elements with particular CSS classes, names
or ids and instantiate JS objects or execute JS functions that are relevant for
those elements.

The key point is that the interface between the HTML and JavaScript should be
the DOM and the CSS. It should *NOT* be scripts embedded in the pages that do
specific things. This can be a bit hard to wrap your head around, but works
beautifully once you get it. Everything else I've ever tried ended up sucking.
A lot.

One important caveat is that you don't want to rely on DOM positioning too much.
It's much better to, for instance, instantiate a JavaScript object that adds
cool list functionality on a div that has the CSS class "list" than it is to
look for the 2nd div on the page, or the div under the div with CSS class X or
whatever.

thanks,
-henry

[Jochen Garcke]

That is a big question :-)

Henry has ideas how to do searches, filtering and selectiones with JS in
a bigger framework, but I don't know too much about that.

But since that is a bigger project, we might reactivate the django-code
I did for the reprint selection before that to get going on that front.
It might be worth to do some JS routines for that to avoid the workflow
over several URLs. But before I look at the code again (after the issue
variants) I wouldn't know what can/should be done.

Jochen

Am 13.03.2011 12:21, schrieb Andres Jimenez:
> I am no JS expert at all, but I have used it in the past and would
> have no trouble writing a few functions.
>
> What is needed?
>

> Andr�s

[Andres Jimenez]

What will do the JS code?

Asynchronous queries to a web service? (desired for the long term?)

Long time ago, I used JS to fill select forms (you choose in the first
select, generates the contens of the second one). That was easy and
required nothing special in the server-side.

Andrés

2011/3/13 Jochen Garcke <gcd...@garcke.de>:

> That is a big question :-)
>
> Henry has ideas how to do searches, filtering and selectiones with JS in
> a bigger framework, but I don't know too much about that.
>
> But since that is a bigger project, we might reactivate the django-code
> I did for the reprint selection before that to get going on that front.
> It might be worth to do some JS routines for that to avoid the workflow
> over several URLs. But before I look at the code again (after the issue
> variants) I wouldn't know what can/should be done.
>
> Jochen
>
> Am 13.03.2011 12:21, schrieb Andres Jimenez:
>> I am no JS expert at all, but I have used it in the past and would
>> have no trouble writing a few functions.
>>
>> What is needed?
>>

>> Andrés

>>
>> 2011/3/13 Jochen Garcke <gcd...@garcke.de>:
>>> Am 13.03.2011 12:08, schrieb Andres Jimenez:
>>>> 2011/3/13 Jochen Garcke <gcd...@garcke.de>:
>>>>>  But some code for
>>>>> selection will be there when the reprint links - finally - will be
>>>>> introduced to production later this year. It probably won't be nice and
>>>>> fancy (as in no JavaScript), but useable.
>>>>
>>>>
>>>> What was the reasoning for not using JS in the OI for this purpose?
>>>
>>> Lack of JS knowledge on my part and neither intention nor time nor
>>> interest to learn it at this stage.
>>>
>>>> I thought the regular webpage was prefered without it, but it was
>>>> assumed JS would be unavoidable in the OI.
>>>
>>> Sure. We want JS in the OI. But somebody would need to do it.
>>>
>>> Jochen
>>>
>>> --
>>> GCD-Tech mailing list - gcd-...@googlegroups.com
>>> To unsubscribe send email to gcd-tech+u...@googlegroups.com
>>> For more options, visit this group at http://groups.google.com/group/gcd-tech
>>>
>>
>>
>>
>
> --
> GCD-Tech mailing list - gcd-...@googlegroups.com
> To unsubscribe send email to gcd-tech+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/gcd-tech
>

--

[Henry Andrews]

Feel free to proceed with your own solution. I can't devote the time to mine
that I'd like and we've waited long enough. I want to make sure we don't mix a
bunch of JavaScript directly into the HTML templates, and I want to make sure
the internal database structure for tracking the more complex relationships in
change history make sense. Otherwise I'll back anything that works and is
reasonably in line with the overall UI goals.

-henry

----- Original Message ----
> From: Jochen Garcke <gcd...@garcke.de>
> To: gcd-...@googlegroups.com
> Sent: Sat, March 12, 2011 5:29:26 PM
> Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding
>issues and series
>

> That is a big question :-)
>
> Henry has ideas how to do searches, filtering and selectiones with JS in
> a bigger framework, but I don't know too much about that.
>
> But since that is a bigger project, we might reactivate the django-code
> I did for the reprint selection before that to get going on that front.
> It might be worth to do some JS routines for that to avoid the workflow
> over several URLs. But before I look at the code again (after the issue
> variants) I wouldn't know what can/should be done.
>
> Jochen
>
> Am 13.03.2011 12:21, schrieb Andres Jimenez:
> > I am no JS expert at all, but I have used it in the past and would
> > have no trouble writing a few functions.
> >
> > What is needed?
> >

> > Andrés

[Andres Jimenez]

The JS involved is simplle and would take probably only hours, but I
am afraid I would waste too much time trying to communicate with
Django.

2011/3/13 Henry Andrews <andrew...@yahoo.com>:

--

[Jochen Garcke]

Am 13.03.2011 13:20, schrieb Andres Jimenez:
> 2011/3/13 Jochen Garcke <gcd...@garcke.de>:

>> For the reprint selection (and others) we need to be able to select a
>> different issue/story in a reasonable way in the OI.
>> Currently the reprint code doesn't seem to be functionally on my dev
>> server, so I can't show you how it is done currently.
>
> How many "selections" will be needed?
>
> I guess:
>
> Contry->Publisher->Series->Issue->Sequence

What I did till now was search directly for a series name and issue
number using our normal search routines. From the result list one than
could choose an issue. From that a sequence.

Jochen

[Andres Jimenez]

2011/3/13 Jochen Garcke <gcd...@garcke.de>:

> What I did till now was search directly for a series name and issue
> number using our normal search routines. From the result list one than
> could choose an issue. From that a sequence.

Whatever that returns a pair id->name_to_display will work

[Andres Jimenez]

What if we use this as our first approach to autocomplete?

http://djangosnippets.org/snippets/269/

My concern is that somebody looking for a series called "Superman"
will have too many options to choose from.

I would suggest selecting entities in order
(Contry->Publisher->Series->Issue->Sequence). Using AJAX is not too
complicated. My main concern would be how fast the autocompletion
would happen...

Andrés

2011/3/13 Andres Jimenez <gand...@gmail.com>:

[Jochen Garcke]

What I was doing, and I think needs to be done, for the selection of
objects is not autocompletion. Precisely because Superman would give too
many results and it is difficult to decide which one of the series to take.
Therefore in the code for the reprint editing, people would enter series
name and issue number at the same time. Optionally publisher, series
year. In some way the same info as currently in a reprint link.
By using both series and issue number the results is already quite
reduced. But still can be large and we need to show reasonable
additional information (e.g. publication date).

Selecting down a tree Country->Publisher->Series->Issue->Sequence is not
the best option IMHO.

Jochen

Am 13.03.2011 14:29, schrieb Andres Jimenez:
> What if we use this as our first approach to autocomplete?
>
> http://djangosnippets.org/snippets/269/
>
> My concern is that somebody looking for a series called "Superman"
> will have too many options to choose from.
>
> I would suggest selecting entities in order
> (Contry->Publisher->Series->Issue->Sequence). Using AJAX is not too
> complicated. My main concern would be how fast the autocompletion
> would happen...
>
>

> Andr�s

[Henry Andrews]

I have an intense hatred of autocomplete. It is a *HORRIBLE* performance suck,
whether you try to do it client-side or with server calls (different kinds of
performance suck, but lots of suck either way). Totally killed the usability of
the other app I work on. It's pretty much the last thing I'd recommend spending
time on. If y'all want it, go ahead, but pay a lot of attention to performance.
You can't just slap some autocomplete library on a form and expect your system
to handle it.

-henry

----- Original Message ----
> From: Jochen Garcke <gcd...@garcke.de>
> To: gcd-...@googlegroups.com
> Sent: Sat, March 12, 2011 8:31:24 PM
> Subject: Re: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding
>issues and series
>

> What I was doing, and I think needs to be done, for the selection of
> objects is not autocompletion. Precisely because Superman would give too
> many results and it is difficult to decide which one of the series to take.
> Therefore in the code for the reprint editing, people would enter series
> name and issue number at the same time. Optionally publisher, series
> year. In some way the same info as currently in a reprint link.
> By using both series and issue number the results is already quite
> reduced. But still can be large and we need to show reasonable
> additional information (e.g. publication date).
>
> Selecting down a tree Country->Publisher->Series->Issue->Sequence is not
> the best option IMHO.
>
> Jochen
>
> Am 13.03.2011 14:29, schrieb Andres Jimenez:
> > What if we use this as our first approach to autocomplete?
> >
> > http://djangosnippets.org/snippets/269/
> >
> > My concern is that somebody looking for a series called "Superman"
> > will have too many options to choose from.
> >
> > I would suggest selecting entities in order
> > (Contry->Publisher->Series->Issue->Sequence). Using AJAX is not too
> > complicated. My main concern would be how fast the autocompletion
> > would happen...
> >
> >

> > Andrés

> >
> > 2011/3/13 Andres Jimenez <gand...@gmail.com>:
> >> 2011/3/13 Jochen Garcke <gcd...@garcke.de>:
> >>
> >>> What I did till now was search directly for a series name and issue
> >>> number using our normal search routines. From the result list one than
> >>> could choose an issue. From that a sequence.
> >>
> >> Whatever that returns a pair id->name_to_display will work
> >>
> >> --
> >> Andres Jimenez
> >>
> >> GPG : http://www.andresin.com/gpg/gand...@gmail.com.asc
> >>
> >
> >
> >
>

[Henry Andrews]

The point of the way I recommend doing JavaScript is that the JS has nothing to
do with the server except:
* Knowing what URL to hit for requests if JS is initiating any requests
* Knowing what CSS classes and HTML elements to look for when hooking on
extended functionality
* Knowing what data format is being used if the JS is reading any responses and
using the data to generate new HTML. If the data format is HTML, the JS just
needs to know where to stuff the HTML.

This way, the JavaScript programmer doesn't need to know anything at all about
the server side, assuming there is good communication with whoever is writing
the server side code and templates.

thanks,
-henry

----- Original Message ----
> From: Andres Jimenez <gand...@gmail.com>
> To: gcd-...@googlegroups.com

[Jochen Garcke]

So, since I doubt the useability of autocomplete at least for the object
selection scenario (it might be different in other areas of the OI) and
it is performance suck (which I kind of expected) following this track
doesn't seem worthwhile for object selection..

Jochen

>>> Andr�s

[Andres Jimenez]

2011/3/13 Jochen Garcke <gcd...@garcke.de>:

> Therefore in the code for the reprint editing, people would enter series
> name and issue number at the same time. Optionally publisher, series
> year. In some way the same info as currently in a reprint link.

If we enter different types of data in a search field, we will need to
"teach" our users in which order information needs to be enteres (just
like it is needed with the reprime links).

I still think we need to either base the whole "find-the-object-thing"
in an advanced search (typing a series' name and issue number and show
ALL ocurrences ) or request our indexers to insert each piece of data
in the proper order.

Would be acceptable to show a simpler versión of the advanced search
in a layer? The search's results would show a link to select the found
issue or sequence.

The layer would be displayed after clicking on a link.

Cheers,

[Henry Andrews]

I believe that what you are proposing is the design I favor, Andrés. The user
clicks on a button, a layer is presented (on the same page, floating above the
regular view, but not a separate OS window) that shows something resembling
advanced search. Probably just a few fields- whatever is most necessary for
finding the object in question. For reprints, series name, year began,
publisher name, issue number, volume number, plus story title (and maybe type?).
The user runs the search, the panel refreshes with results, and the user
selects the desired result. The user can refine the search and move from page
to page of search results all within that panel.

This pattern will solve the vast majority of many-to-many relation UI problems
and not require the writing a separate parser for various formats. It can be
done in such a way that if you get an exact match then you can choose as a
search option to automatically select it (kind of like Google's "I'm feeling
lucky" button).

Having implemented something like this before (but not in jQuery), the biggest
pain was getting the search+result list interface to be sufficiently
self-contained that you could have more than one of them on a given interactive
page.

thanks,
-henry

----- Original Message ----
> From: Andres Jimenez <gand...@gmail.com>

> To: "gcd-...@googlegroups.com" <gcd-...@googlegroups.com>
> Cc: Jochen Garcke <gcd...@garcke.de>

> Sent: Sun, April 3, 2011 11:33:03 AM
> Subject: [gcd-tech] Javascript in OI WAS [gcd-main] Deleted and re-adding
>issues and series
>