[gcd-software] Agenda for Software Planning

[Henry Andrews]

Hi folks,
This is not as detailed an agenda as I originally intended, but I really just want to get some discussions going! Everything gets busy at once around here...

I see the concerns of software breaking up into some major areas, as follows:
USER INTERFACE
===============
This, to me, is where we can make the most dramatic changes. The UI, by necessity, has been done in a rather basic fashion, and there is much room for improvement. I see two general areas for improvement:

*Presentation*
Are we presenting our existing data in the most effective and useful way? I'm guessing the answer is "no, not really" :-) The overall UI is a pretty simple adaptation of the prior web site, cleaned up into something resembling modern HTML+CSS usage. There are some things I like about it, but really it is the way it is because that's where we had left it when the server crisis happened.

Let's think about what we like about the site. Let's think about what we like in other sites (whether they are comic book sites or other content presentation sites). And let's see what we can do to show off our data better. Data display is what we're all about to the vast majority of our users, so we should make it as effective as possible. Both in terms of the design of the pages we have, and in terms of adding new and different views of the data.

*Interaction*
On the OI side, we need a much more rich web application environment. This means JavaScript. Ages ago we decided to avoid JavaScript in the end-user UI (for accessibility reasons) but use it as needed in the OI. As seen on gcd-tech in the last few days, we've really hit the point where we need JavaScript to make a non-clunky OI as we start involving more and more complex data relationships. What do we want here? How much do we want to support non-JavaScript users in the OI? And are there more basic (HTML/CSS) changes that we could do to produce a better-designed OI? Certainly we could use a more innovative color scheme ;-)


INTEGRATION
===========
There's a whole big web 2.0 world out there, and we should have a long range plan to be a part of it.
* How do we want to approach putting together a Web Services API? How will we handle the evolving data structures? What about incoming data?
* What about the Semantic Web?
* Search plugins and/or toolbars for Browsers- small projects that can make us really visible.
* How about data interchange with other sites? We have an arrangement of sorts with INDUCKS already, and Greg Gatlin of atlastales.com has mentioned that setting up an interchange with his site is something he'd be interested in. How would we go about this? How would we resolve (or agree to leave in place) disagreements in the data?
* Are there hooks to external social networking sites we can/should consider? Note that as discussed elsewhere, putting social networking features into the GCD itself is unlikely- that's more something we want data clients to do.

I18N / L10N
=========
What's our internationalization / localization plan? So far, it's mostly "Jochen translates stuff into German" :-) Translation is good. Making certain we can handle RTL text as well as LTR text is good.
But what about going beyond translations?

Are there things we can do to make our site more attractive in each culture? Does our presentation just not work as well for some cultures or artistic traditions? For instance, it's been noted on the lists that Japanese manga is not necessarily produced with the same division of labor as U.S. comics. Are there sites similar to ours but focusing on other languages that we could integrate with in some way?

MOBILE
======
How's our mobile presence? Does our UI work well on smart phones? Recent experience with folks using our data dumps suggests our data is useful for app developers, but are there special concerns for mobile apps that should inform our integration / API efforts?

SEARCH
=======
It needs to be better :-) I think this one's actually pretty well understood and I'd like to see it play out on gcd-tech for a bit, so lets table this area for now.

DATA STRUCTURES
================
We have extensive plans here. The question isn't so much what to do- there are some details that need work, but that sort of thing isn't really the type of high-level question this committee is trying to answer. We just need to think about overall priorities and how this fits in with other things like UI development and integrations.

TESTING
=======
We could really use some automated testing. Or even some real documented test cases that we can track for manual execution during beta testing. I sporadically try to get this going but it's hard to focus on it. And then we ship a bug and it's a problem again :-(

SUPPORT APPS
=============
Single sign on! OK, we already know we want that.
Do we want to keep the error tracker? Or merge it into the queue system in the main app? It would be very easy to do that and eliminate an interface.
Are there any changes we want to make to the wiki and how it links to the main app?
Are there other 3rd-party apps that we should integrate to do useful things for us?


OK, there are a bunch of ideas. Remember the whole belief/goal/plan/measurement structure I outlined in the last message ( ). We don't need to start with things in that form, but remember that that's where we want to go. So start throwing ideas out there. I'll let things go for a bit and then start trying to focus each area into some specific goals. Remember to keep it high-level. We're planning direction over the next four to five years, not the next few weeks or months! And feel free to add more large agenda areas if you think I missed one. As I said, I ended up writing this rather quickly as I never seem to get enough time to do whatever it was I originally intended :-)

Hopefully you all haven't wandered off while I was distracted ;-) Have at it!

thanks,
-henry

[Alexandros Diamantidis]

Some more replies to assorted points in the agenda...

> INTEGRATION
> ===========
> There's a whole big web 2.0 world out there, and we should have a long range plan to be a part of it.
> * How do we want to approach putting together a Web Services API? How will we handle the evolving data structures? What about incoming data?

A project similar to the GCD is MusicBrainz, which is indexing music
recordings, artists and similar info. I think looking at their API will
be instructive:

http://musicbrainz.org/doc/XMLWebService

(not saying that we should copy it, just look for inspiration here).
Note that this API mostly covers extracting data, not importing.

For further inspiration, maybe take a look at their blog:
http://blog.musicbrainz.org/

Data output might be more readily useful as JSON and not as XML
(although threre are no fundamental differences I think).

I don't know if the Testimony guys are still involved in the GCD, but
contacting them might be a good idea. Testimony
(http://testimony.sourceforge.net/) was an off-line indexing tool for
the GCD.

In the outgoing direction, I don't think it will be difficult to
maintain compatibility with older versions of a web services API - for
example, if the initial version is more text-based and later versions
move to references for creators, the old API will just need to resolve
these references.

> * Search plugins and/or toolbars for Browsers- small projects that can make us really visible.

In Firefox, it's easy to add a keyword search for simple serches - just
right-click on the search field and select "add a keyword for this
search".

> * How about data interchange with other sites?

We might also consider using the Previews text files and consumer order
forms provided by Diamond, and the lists of new comics releases from
http://www.comiclist.com/ to better co-ordinate adding new US books, and
help make the GCD more complete for them.

> DATA STRUCTURES

> We have extensive plans here. The question isn't so much what to do- there are some details that need work, but that sort of thing isn't really the type of high-level question this committee is trying to answer. We just need to think about overall priorities and how this fits in with other things like UI development and integrations.

All my thoughts about i18n were dependant on changes to the data
structure, so they're pretty much blue sky for now. Now that I think
about this, I don't know how realistic they are...

> Do we want to keep the error tracker? Or merge it into the queue system in the main app? It would be very easy to do that and eliminate an interface.

Well, this could potentially allow better integration with other aspects
of the site, but would also take some work. INDUCKS has taken this road
I believe:

http://coa.inducks.org/discuss.php

[Henry Andrews]

Hi Alexandros,
I'm splitting my reply to this message of yours based on sub-topic. The largest chunk is about the API, which I really think we should spend some serious time on in this committee as it is so frequently requested.

----- Original Message ----
> From: Alexandros Diamantidis <ad...@hellug.gr>
>
>> * How do we want to approach putting together a Web Services API? How will we
>> handle the evolving data structures? What about incoming data?
>
> A project similar to the GCD is MusicBrainz, which is indexing
> music recordings, artists and similar info. I think looking at their API
> will be instructive:
>
> http://musicbrainz.org/doc/XMLWebService
>
> (not saying that we should copy it, just look for inspiration here).

This looks very relevant! Note that the Lucene search query format they mention refers to Lucene, the library that backs Solr, the search system that Tim Leahy is working on integrating into the GCD. The design of the MusicBrainz API looks very straightforward and the project is quite similar.

> Data output might be more readily useful as JSON and not as XML
> (although threre are no fundamental differences I think).

Different apps will prefer different formats, most likely. There are pros and cons to each, and both can be supported at the same time.

> I don't know if the Testimony guys are still involved in the GCD, but
> contacting them might be a good idea. Testimony (http://testimony.sourceforge.net/) was
> an off-line indexing tool for the GCD.

Whoever is updating their SourceForge page is keeping at least enough of an eye on the GCD to know that the tool won't work with the new system. I'm guessing that means they're not interested enough to speak up on the list, but if anyone is still around who knew them perhaps they could check in? They had stopped doing active development long before I joined.

> In the outgoing direction, I don't think it will be
> difficult to maintain compatibility with older versions of a web services API
> - for example, if the initial version is more text-based and later
> versions move to references for creators, the old API will just need to
> resolve these references.

My main concern with developing an API now while our structures are still changing is that some of the fundamentals will become more complex- like nearly all relationships becoming many to many. We can handle that in the API, but it will require some forward thinking. This is why I've pushed against attempts to get a quick API up and running in the past. I'm less worried about things like the characters or credit fields- as you say, we can produce composite fields from newer, more fine-grained fields. I would tend to add apis like

http://rest.comics.org/issue/1234/story/2/characters/as-text/

Or something similar such that we could reserve the nicer formats for the preferred URLs.

But what happens to the unique issue IDs when an issue appears in more than one series? Most likely, we use the id on the series-issue join table as most people will want to "uniquely" identify an issue within a given series. That was the thought the last time I kicked the idea around with someone (I have no recollection as to who or whether it was on-list or off). But maybe we'd prefer to uniquely identify the issue itself and include in its data multiple sets of series-linking information. These are the kinds of things we should think through before structuring the API, even if it only is intended to work on our current data at the moment.


thanks,
-henry

[Henry Andrews]

----- Original Message ----
> From: Alexandros Diamantidis <ad...@hellug.gr>

>

>> * How about data interchange with other sites?
>
> We might also consider using
> the Previews text files and consumer order forms provided by Diamond, and the
> lists of new comics releases from http://www.comiclist.com/ to better
> co-ordinate adding new US books, and help make the GCD more complete for
> them.

That's an interesting idea. If not a direct import, perhaps a weekly check and a notice to GCD main about what needs attention? There are multiple levels of integration possible there from full import to simple automated reminders.

thanks,
-henry

[Henry Andrews]

----- Original Message ----
> From: Alexandros Diamantidis <ad...@hellug.gr>
>

>> Do we
>> want to keep the error tracker? Or merge it into the queue system in the
>> main app? It would be very easy to do that and eliminate an interface.
>
> Well, this could potentially allow better integration with other aspects
> of the site, but would also take some work.

Honestly, it's not much work at this point. We already have an application that takes user input and puts it in queues for people to accept, work on (with emailed comments), and resolve. A very light veneer of error-tracking terminology and some new queue pages would pretty much take care of it.

thanks,
-henry

[Henry Andrews]

>> * Search plugins and/or toolbars for
>> Browsers- small projects that can make us really visible.
>
> In Firefox, it's easy to add a keyword search for simple serches - just
> right-click on the search field and select "add a keyword for this search".

That's something anyone can do on their own browser, right? I'm thinking more along the lines of the dedicated toolbar extensions that put particular buttons (and search forms) into the UI related to a site. Obvious ones are Yahoo, Google and Facebook. Toolbars that take you to your OI queues or display notifications of events related to your queues, plus search? I don't really know what can be done with these things or how much effort it is but it seems worth a look. And preferably for IE as well if such things are possible.

thanks,
-henry

[Alexandros Diamantidis]

* Henry Andrews [2010-05-23 13:19]:

> > Data output might be more readily useful as JSON and not as XML
>

> Different apps will prefer different formats, most likely. There are pros and cons to each, and both can be supported at the same time.

Right, I mentioned JSON because it's directly usable from jQuery and it
will benefit our planned JS OI improvements, but I see parsing XML is also
trivial so...

> They had stopped doing active development long before I joined.

The testimony developer active in gcd-tech was Carlos Tasada (ctasada at
gmail), whose last message was five years ago...

> But maybe we'd prefer to uniquely identify the issue itself and
> include in its data multiple sets of series-linking information.

This seems conceptually cleaner to me... An issue is a unique object, so
the API should offer a unique ID to find it, and then one can also ask
for further data associated with it (such as series, which might indeed
be multiple). Are we interested in minimizing the API calls needed to
retrieve all information needed to display, say, an issue or a series? I
think any API users should be urged to cache retrieved data as much as
possible (although asking the server if the data has gone stale might be
as expensive for us as re-retrieving the data).

Alexandros

[Alexandros Diamantidis]

> > We might also consider using the Previews text files
>

> That's an interesting idea. If not a direct import, perhaps a weekly check and a notice to GCD main about what needs attention?

I was thinking of the latter. Issue data per solicitation very often
differs from what's actually published (creators, number of pages,
publication date, story titles, all can change). To be sure that the
data is accurate, I was thinking of a new part in the OI application
displaying a list of issues (taken from the new releases list) with
links to Previews' solicitation info where possible, and a field
indicating if this item has been indexed in GCD, or if a skeleton
exists, or if both are needed.

The Previews text files are quite structured, and it shouldn't be too
difficult to import them in a DB, but we might want to contact Diamont,
both to be sure they don't mind us using them like this, and to see
whether they might offer the data directly (I've saved all Previews text
files since January 1999 from the online comics shop I'm ordering from,
but Diamond should have older files as well).

Now that I'm thinking about this, when the "standard numbers" issue
relationship is implemented, we might want to index Diamond's order
codes (which look like "AUG08 0888" for the 888th item offered in
August 2008 Previews) as well as Amazon's ASIN numbers
(http://en.wikipedia.org/wiki/ASIN). Sure, they're not actually part of
the comic itself, but they are quite interesting for many purposes.
Probably a question for the policy list when the time comes...
Other distributor or important online commercial or other DB codes might
also be considered (don't know of any other interesting ones off hand).

Alexandros

[Alexandros Diamantidis]

* Henry Andrews [2010-05-23 13:19]:

> >> Do we want to keep the error tracker? Or merge it into the queue system in the main app?
>

> Honestly, it's not much work at this point.

Well, in that case I don't see why not. INDUCKS does have an integrated
bug database: http://coa.inducks.org/discuss.php

Comicbookdb.com also has an integrated problem report form, but since
I've never actually used it, I don't know how exactly it works - it
might just send a message to the admins (Comicbookdb has an internal
messaging system).

Bugzilla does have a rich feature set, but you having to maintain a
private branch seems like much work for little gain, since
errors.comics.org seems to make little use of any advanced features.

Alexandros

[Henry Andrews]

----- Original Message ----
> From: Alexandros Diamantidis <ad...@hellug.gr>

> To: gcd-softwar...@googlegroups.com
> Sent: Mon, May 24, 2010 2:35:31 PM
> Subject: Re: Error tracker (was Re: [gcd-software] Agenda for Software Planning)
>
> * Henry Andrews [2010-05-23 13:19]:
>>>> Do we want to keep the
>>>> error tracker? Or merge it into the queue system in the main app?
>>
>> Honestly, it's not much work at this point.
>
> Well, in that case I don't see why not. INDUCKS does have an integrated
> bug database: http://coa.inducks.org/discuss.php
>
> Comicbookdb.com also has an integrated problem
> report form, but since I've never actually used it, I don't know how exactly
> it works - it might just send a message to the admins (Comicbookdb has an
> internal messaging system).

It would be easy enough for us to add one. I think there's a contrib app in django already, actually.

> Bugzilla does have a rich feature set, but you having to maintain a
> private branch seems like much work for little gain, since
> errors.comics.org seems to make little use of any advanced features.

In fact, 99% of the work on errors.comics.org was stripping out features and making the ones that were left more human-readable. I actually think that converting it over to being part of the OI would be both easy and a crowd-pleaser, if only to eliminate yet another login. Also, we could allow folks to automatically link changes to error reports and therefore not have to keep putting in "this was contributed by so-and-so via error report".

thanks,
-henry

[Alexandros Diamantidis]

> > In Firefox, it's easy to add a keyword search for simple serches
>

> That's something anyone can do on their own browser, right?

Right!

> I'm thinking more along the lines of the dedicated toolbar extensions that put particular buttons (and search forms) into the UI related to a site. Obvious ones are Yahoo, Google and Facebook.

For those (as well as for other private sites), I think we need to have
a piece of HTML/Javascript that can be referenced from other sites and
creates a small standalone GCD search form. I'm not familiar with what
APIs are offered by those sites for such purposes... A Facebook app
should be quite popular.

I have a professional iPhone developer friend. I'll ask him how easy it
would be to create an iPhone GCD search app. I think iPhone apps can
just wrap a web page, so it might not be difficult to just have an app
for simple and advanced GCD searches.

> Toolbars that take you to your OI queues or display notifications of events related to your queues, plus search? I don't really know what can be done with these things or how much effort it is but it seems worth a look.

For someone with some relevant experience, it should't be too
difficult... A few minutes googling resulted in the following links:

For IE:

Powering up with Internet Explorer Extensibility
http://blogs.msdn.com/b/ie/archive/2005/09/06/461675.aspx

Creating Custom Explorer Bars, Tool Bands, and Desk Bands
http://msdn.microsoft.com/en-us/library/aa969320.aspx

And here:
http://stackoverflow.com/questions/2799496/firefox-xul-toolbar-with-javascript-to-ie

> Writing an IE toolbar requires C++, the Windows API and Microsoft COM.
> If you have the paid version of Visual Studio then you can also use ATL
> to simplify some of the work.
[...]
> I want to warn you though that creating an IE toolbar can be quite
> painful. If you are serious then I recommend that you learn and
> understand the basics of COM and ActiveX first.

(not very encouraging...)

For Firefox:

Firefox Toolbar Tutorial
http://www.borngeek.com/firefox/toolbar-tutorial/

> Extension development isnοΏ½t difficult, although some basic programming
> knowledge is required. There are three basic areas I recommend that
> you should be somewhat familiar with: XML, JavaScript, and CSS.

(much better!)

For IE 7+, FF 2+, Chrome: OpenSearch

http://www.opensearch.org/Home
http://en.wikipedia.org/wiki/OpenSearch

With OpenSearch auto-discovery, a web site can signal to the browser
that there is a search mechanism available, and how it can perform
searches. OpenSearch-aware browsers then offer an option to add a site
search in their search bar drop-down menu.
http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_description_document

Alexandros

[Henry Andrews]

----- Original Message ----
> From: Alexandros Diamantidis <ad...@hellug.gr>
> To: gcd-softwar...@googlegroups.com

> Sent: Mon, May 24, 2010 3:06:18 PM
> Subject: Re: Search plugins / toolbars (was Re: [gcd-software] Agenda for Software Planning)
>
> I have a professional iPhone developer friend. I'll ask him how easy it
> would be to create an iPhone GCD search app. I think iPhone apps can
> just wrap a web page, so it might not be difficult to just have an app
> for simple and advanced GCD searches.

There are at least two or three folks using our data in iPhone apps already. At least one of them (Sascha Herpers) is on gcd-tech. I think there's another iPhone app, and an Android app as well.

thanks,
-henry

[Alexandros Diamantidis]

* Henry Andrews [2010-05-24 15:14]:

> There are at least two or three folks using our data in iPhone apps already. At least one of them (Sascha Herpers) is on gcd-tech. I think there's another iPhone app, and an Android app as well.

Oh, that's fine then - should have expected it! I have neither an iPhone
nor an Android one, so... ;-)

[Will Allred]

This sounds like a relatively easy win, then, and a good idea.

Will
______________________________

Will Allred <wal...@gmail.com>
http://www.quantumzone.org/ http://www.comics.org/

[Philip Rutledge]

(sorry for being out of touch, this has been sitting as a draft for a while now... a couple of items have already been suggested by Alexandros)

I've been using Google Chrome as my primary browser for a while and their "TAB-Search" capability (http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=95655) allows you to enter "comics.org" in the address bar, press tab and then it allows you to put in a search term in the address bar which is a small shortcut I use a lot.

The other search option would be to extend the browser's search engine to add comics.org to their search options

IE:  http://www.microsoft.com/windows/ie/searchguide/en-en/default.mspx

Firefox:  http://www.wikihow.com/Add-a-Custom-Search-Engine-to-Firefox's-Search-Bar-(Windows-Version)

I haven't tried these yet but it seems straightforward but it is a user side action.  It would be nice to be added to the list of optional search engines that users can automatically enable.  Not sure how this is done but it could be another option to look into.

Finally another thought would be to have a GCD button/badge that we could have people add to their blogs/wikis/sites.  Just a simple, small panel with the GCD logo and the default search entry field.  It would increase the visibility of the GCD and allow people to easily link to the GCD.  

In general I think that there could be a lot more things that could be done to draw people to the site.  The folks that know about GCD and use it in their blogs and such link and reference it so it would be nice to get the readers of those sites to get to the GCD quickly as well.

I think a toolbar extension is also a good idea but I think that would only be for advanced users that are doing a lot of indexing.  Unfortunately toolbars have also started getting a bit of a bad rep lately with Bing, Ask, Yahoo, Google and a bunch of others all wanting to auto install their own toolbars.

Phil

[Philip Rutledge]

I'm also a big proponent of having a web services API for the site.  Stepping away from the technical details for a second I was thinking about how we would envision these API's being used.

I know that the ultimate goal would be to have a full suite of APIs that could be used for accessing all of the system's data and eventually for two way data exchange however I'd like to suggest starting small and seeing what happens.

When I browse around the web I find many sites (wikis, blogs etc) that are manually entering data that is maintained in the GCD indexes.  If we had just a simple set of APIs that allowed read only access to the basic data for cover and main story sequence credits then I'd think that would satisfy a large majority of the sites out there.  If we could get the word out and get a few folks to start using these APIs then this could be a draw to get them to double check data already in the system, enter missing data and further publicize GCD (eg: a simple GCD badge on their site) and it saves them the hassle of having to manually enter the data.

I see all the great data (eg: on the wikia sites) and just think that if we could partner with them to get them to enter data in the GCD and then present it via the wikia site then it's a win-win for both sides.

Phil

[Philip Rutledge]

I think this is a great idea!  It would help with ensuring that we're keeping up with the new releases (for North America at least).

I would assume the workflow would first add in the data from the solicitation information but have a state of "solicited" or something to indicate that it's still pending which changes to "shipped" (or "skeleton" once the issue is shipped and then goes through the normal indexing process to validate that the information is indeed correct.  The Diamond order code is the unique key that would allow you to track the data from solicitation through any changes and finally to through the release data.

BTW:  Diamond does have it's shipping archive online:  http://www.diamondcomics.com/public/default.asp?t=3 although they seem to have just pulled everything older than 2009.  I had previously downloaded their archives back to 2006 but I know it's also available at comiclist and other places.

I agree that it would be great to get this information directly from the Diamond source but have never looked into it.  It seems that there are three types of info regularly published the monthly solicits, the weekly new releases and the regular (is it weekly?) changes to announced materials.

Phil

[Philip Rutledge]

I also think integrating the error tracker in the OI is a big plus!  Removing any additional barriers to having users flag errors is a plus, I wonder how many folks see something wrong but can't be bothered to log in and report it.

Beyond just the ease of being able to easily flag an error without having to log into another app another benefit I would see is that we could use the data to present "flags" in the issue information so that if someone else is browsing the data they can log in and edit the issue data in place.  Currently the information is "siloed" in the error tracker which many people don't look at (I think just editors that can be assigned these errors right?).  It would also reduce duplicate reporting of errors as well (which I recently did since I didn't search the current list of errors first).

Phil

[Alexandros Diamantidis]

* Philip Rutledge [2010-05-27 14:22]:

> Currently the information is "siloed" in the error tracker which many
> people don't look at (I think just editors that can be assigned these errors
> right?).

No, anyone can register to the tracker and assign errors to themselves
(or fix them and close them right away), but I don't think many people
apart from editors do...

[Philip Rutledge]

A while back I checked out the wiki for this http://docs.comics.org/wiki/Error_Tracker_Workflow and currently it does say editor in step two so I just assumed there was some user account checking prohibiting non-editors from being assigned in bugzilla.  There were a few errors I thought I could address and wanted to validate how the workflow was setup, when I saw this in the wiki I stopped there and didn't try to assign any to myself.

Knowing this maybe I'll go back now and fix a couple of those error reports I saw

Thanks

Phil

[Jochen Garcke]

Am 28.05.2010 15:20, schrieb Philip Rutledge:
> A while back I checked out the wiki for
> this http://docs.comics.org/wiki/Error_Tracker_Workflow and currently it
> does say editor in step two so I just assumed there was some user

I changed the wording on that page to any indexer, someone might
double-check if I didn't miss it somewhere.

Jochen

[Jochen Garcke]

Am 23.05.2010 22:19, schrieb Henry Andrews:
>> I don't know if the Testimony guys are still involved in the GCD,
>> but contacting them might be a good idea. Testimony
>> (http://testimony.sourceforge.net/) was an off-line indexing tool
>> for the GCD.
>
>
> Whoever is updating their SourceForge page is keeping at least enough
> of an eye on the GCD to know that the tool won't work with the new
> system. I'm guessing that means they're not interested enough to
> speak up on the list, but if anyone is still around who knew them
> perhaps they could check in? They had stopped doing active
> development long before I joined.

The 'new system' refers to some html changes on the old site some years
ago I think and concerns the import of data from the website. I used the
tool with old u/d download tool a couple of times.

Jochen

[Jochen Garcke]

Am 27.05.2010 20:43, schrieb Philip Rutledge:
> Finally another thought would be to have a GCD button/badge that we
> could have people add to their blogs/wikis/sites. Just a simple, small
> panel with the GCD logo and the default search entry field. It would
> increase the visibility of the GCD and allow people to easily link to
> the GCD.

I got questions for this from one or two German websites...

But people would nowadays expect a full search, so this should be done
after the new search capabilities are thre.

Jochen

[Henry Andrews]

[finally going through, gathering notes, and replying to threads I missed]

----- Original Message ----
> From: Alexandros Diamantidis <ad...@hellug.gr>

> Subject: Re: Importing from other sites (was Re: [gcd-software] Agenda for Software Planning)
>
> > > We might also consider using the Previews text files
>

> Now that I'm thinking about this, when the "standard numbers" issue
> relationship is implemented, we might want to index Diamond's order
> codes (which look like "AUG08 0888" for the 888th item offered
> in August 2008 Previews) as well as Amazon's ASIN
> numbers (http://en.wikipedia.org/wiki/ASIN). Sure, they're not actually part
> of the comic itself, but they are quite interesting for many
> purposes. Probably a question for the policy list when the time
> comes...
>
> Other distributor or important online commercial or other DB codes
> might also be considered (don't know of any other interesting ones off
> hand).

I agree that these things are interesting, and could be easily tracked. The idea of tracking distributor codes has been discussed many times and is mostly waiting for some time when we can actually implement support instead of debating it in a vacuum. For some reason, distribution discussions tend to get quite heated, but I think the overall discussion is more about how to accept the data, not whether to accept it. Where we want to start drawing the line with retailer codes I don't know- that will be a policy discussion. But hey, the decision-making motions passed, so we have a process and should soon have action!

thanks,
-henry