The story so far...
Henry Andrews
I've been going back over the messages on this list so far as we seem to have reached a bit of a lull, and wow, we've really covered a lot of ground. I was going to try to distill things into beliefs and goals, but I'm finding that a bit overwhelming right now so I think I'm just going to do a bit of summarizing to get things started again, using the major headings from my initial agenda message. I'm not trying to capture every significant idea (I have some more extensive but not well-organized notes that serve that purpose). I'm just trying to note where we are and whether we need more brainstorming on a topic or whether it seems ready to boil down to deliverables.
IF I MISSED SOMETHING:
Please do let me know if I missed something you felt was a key idea, or if I missed an entire topic! :-)
USER INTERFACE
===============
*Presentation*
--------------------
We've made a really good start on this in two related areas: Phil's push for different front page (and other) views based on the type of user, and Jason's evaluation of and proposal for the front page. There's a lot of mileage left in both of these discussions, I think.
Does anyone feel that there's much (beyond the type-of-user stuff) to say about our basic data presentation pages like the issue page? There are some long-desired features (like allowing folks to turn off displaying certain sequence types like ads) that we know we want, but I'm more talking about general layout and look-and-feel stuff. Lionel touched on this with his talk of an inverted-L layout, I think, and Phil also covered the documentation side with points about integrating most of what's on the wiki right now into the site itself as it's not really very wiki-ish content.
*Interaction*
------------------
We brought up a few JavaScript usages but not much in the way of high-level goals. This might just need some more experimentation and initial approach definition on gcd-tech before we can get more visionary about it, but I thought I'd at least mention it again.
The one main suggestion in this area was a more spreadsheet-ish way of entering data in the OI that's more like creating an offline file and uploading it. But without the offline/uploading part.
INTEGRATION
===========
*REST API*
-----------------
I think we all agree this is really important. We've got a belief here that we just need to articulate. We've got some long-term goals. And we have several ideas on where to look for similar APIs and how to handle particular circumstances.
What we're lacking are practical short-term goals and plans for how to get this started. I'd like to focus on that a bit. Should we try to launch a very small trial service and grow a larger service from that? Or should we invest in design up front and do a bigger launch based on that? Or should we split the difference? Something else?
(Also, I still want to look into how we could do something with the whole Semantic Web concept, but I'm pretty hazy on that in general)
*Search / Toolbars / Add-ons*
-------------------------------------------
Lots of great discussion here about search integration and toolbars- the challenges will just be getting folks who have time to do these things, especially with so many other high-priority things. Browser and Facebook-type integrations were discussed. Possibly this is just something we should advertise needing in hopes that folks who do this sort of work would be interested in helping even though they wouldn't want to join the main site development project?
*Data Integration*
--------------------------
This to some degree depends on the API, but we got several good ideas about integrating with things like Diamond previews and other data sources for checking what work we need to do. This will probably produce some pretty straightforward short-term goals.
I18N / L10N
=========
Good discussions here about translating data (and not just labels) and the myriad requirements around names (multiple translations and transliterations).
Alexandros pointed out that trying to design different presentations for different languages/regions/communities was more likely to grow naturally than to need designing up front.
I think we have a pretty good understanding of where the challenges are for this, even when we don't know how to solve them. We just need to figure out what our short and long term goals are and what plan we want to have to start doing more than just having a few German translations ;-)
MOBILE
======
We didn't cover this much except to note that some folks have already started developing apps. I have suggested to one who was in touch with me recently that he should announce his app on gcd-tech as I'm sure folks would like to see it. I'm not sure we need much more on this topic right now.
DATA STRUCTURES
================
As noted in the original agenda message, we have extensive plans here. We might want to set some goals and priorities as part of this committee, though. And I mean beyond my short term goals that have been posted to gcd-tech.
TESTING
=======
We didn't cover this at all. Which doesn't bother me too much as I understand the problem really well. And I know many solutions we could implement. I'm far less certain how to staff and/or prioritize those solutions, though.
SUPPORT APPS
=============
We're going to fold the error tracker into the main site. That will be pretty easy to write up as a set of goals when the time comes.
OTHER
======
Phil's karma point system is worth further discussion. I especially like the idea of being able to commission projects or make requests based on points, which makes it more than just a "hey, I got a new sparkle on my profile" sort of thing. I still need to spend more time writing a response to the original message on this topic.
Jason raised some good points about how we should figure out what we are trying to get from the site analytics- which metrics are important to us and why?
=========
=========
Comments on the state of things? Did I miss anything?
thanks,
-henry
Alexandros Diamantidis
> *Presentation*
> --------------------
> We've made a really good start on this in two related areas: Phil's push for different front page (and other) views based on the type of user, and Jason's evaluation of and proposal for the front page. There's a lot of mileage left in both of these discussions, I think.
I don't have any specific ideas about this area, but I think it's always
attractive for a project like the GCD to have a blog-like news section,
if not in the front page, prominently linked from there. I'm not sure if
planning this falls on this committee, the membership committee, or the
web-site team when that gets going.
Another idea I had is to extend the series timeline and issue details
pages with more info (perhaps selectable by visitors). I think you have
plans already for this, but wanted to mention it just the same. For
example, let's say you want to see a list of the writers and artists for
each issue of a long-running series - even limit it to some specific
feature. Me, I'd just do it with a SQL query, but I think it would be
quite useful to have a nice interface to get such reports in the site.
The main difficulty here is the user interface, I think. A Javascript UI
allowing dragging and dropping fields, labels etc. might be the way to
go. Someone with experience designing web interfaces would be very
valuable ;-)
> *Interaction*
> ------------------
> We brought up a few JavaScript usages but not much in the way of high-level goals. This might just need some more experimentation and initial approach definition on gcd-tech before we can get more visionary about it, but I thought I'd at least mention it again.
Well, I think there are so many areas that JS can help, that the
high-level goal should be: Help users (visitors, indexers and editors)
accomplish common tasks with the maximum efficiency and minimum
frustration.
Common tasks can be broken in steps, and then we can think of how to
make each step quicker and easier using JS. Given the limited
development capacity of the project right now (i.e. only Henry as far as
JS development is concerned? :-/) maybe a better course would be to try
to improve some very obvious tasks (for example, reordering stories in
an issue or issues in a series by drag-and-drop, or field
auto-completion) and then solicit further suggestions in the main list,
pointing to the implemented examples to show what's possible.
> *REST API*
> -----------------
> What we're lacking are practical short-term goals and plans for how to get this started. I'd like to focus on that a bit. Should we try to launch a very small trial service and grow a larger service from that? Or should we invest in design up front and do a bigger launch based on that?
How about starting some simple ad-hoc query API, with the understanding
that it is unstable and not final, and announce it to interested parties
with a request for comments? An open alpha release, as it were. While we
*can* try to design a complete API, even taking into account plans for
changes to the internal schema, it's probably easier to "evolve" it
along with the applications who'd like to use it, and then release it as
a frozen milestone when it seems to cover existing apps' needs with some
measure of completeness.
> TESTING
> =======
> We didn't cover this at all. Which doesn't bother me too much as I understand the problem really well. And I know many solutions we could implement. I'm far less certain how to staff and/or prioritize those solutions, though.
Your initial New Fun roadmap mentioned some test infrastructure
equirements:
http://docs.comics.org/wiki/Release_New_Fun#Test_Infrastructure
Is the plan still something like this? The problem might be that we're
not very familiar with automated testing (at least, *I'm* not, although
I've read various articles about how necessary it is).
> Comments on the state of things? Did I miss anything?
I don't think so...
PhilR
for the past week... and here it is...
On Jun 8, 2:06 am, Henry Andrews <h...@cornell.edu> wrote:
> USER INTERFACE
> ===============
> *Presentation*
> --------------------
are multiple aspects we could discuss for some time. Here are a few
of my thoughts just looking again at the pages tonight - some are
probably a bit detailed and may have already been discussed.
I touched on these in my previous thread but a couple of specific
items:
* Enhanced capabilites for User profiles/logged in users, eg: saved
searches
* I know search is being worked on but the presentation of the search
results and the ability to refine those results (sorting, filtering
etc) is an area that I think we can discuss. Also the ability to
create more complex searches with boolean logic.
In terms of the actual data presentation:
* SERIES Page
** It's been discussed before but hyperlinks for series tracking info
would be helpful
** Another aspect of the browser vs indexer is the two "Status"
tables, while informative for the index the browser just wants to get
to the data and I think the two tables make it a bit confusing. Also
I know there was a thread about refining the "completness" status and
it's presentation.
** A minor point would be to make the series image "click-able" to
take you immediately to the cover gallery (but also keep the explicit
link)
** I find the data in the "Details by Issue" and "Series Timeline" to
be redundant between the two views. In the "Details" view I like the
tabular presentation and it would be nice to be able to sort/filter
and add/remove adhoc columns. In the "Timeline" view it has the same
columns but adds in the rows for the missing months and while that's
interesting I would think that if you are looking at this view you're
most interested in the allocation of the issues over time. So I was
thinking a calendar grid with just the links to the issues would be
most informative:
+------+-----+-----+-----+-----+-----+-----+-----+-----+-----
+-----+-----+-----+
| YEAR | JAN | FEB | MAR | APR | MAY | JUN | JUL | AUG | SEP |
OCT | NOV | DEC |
+------+-----+-----+-----+-----+-----+-----+-----+-----+-----
+-----+-----+-----+
| 1997 | 419 | 420 | 421 | 422 | 423 | 424 | -1 | 425 | 426 |
427 | 428 | 429 |
+------+-----+-----+-----+-----+-----+-----+-----+-----+-----
+-----+-----+-----+
| 1998 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 |
440 | 441 | |
| | | | | | | | | | 439
| | | |
+------+-----+-----+-----+-----+-----+-----+-----+-----+-----
+-----+-----+-----+
* ISSUES Page
** A suggested enhancement for handling the variant covers would be to
present the cover image within the region for that sequence so the
credits and the image are "linked". Also could the "cover thumbnails"
disclaimer be relocated to the bottom of the page? the layout pushes
down the second sequence in many cases.
** The table of contents on the right was strange to me at first since
I expected it at the top of the page.
** The ability to expand/collapse sequences might be a nice
enhancement
** Auto creating a hyperlink for each creator's name that auto
generates a search (or a search icon next to the name) would be a nice
way to find other work by that creator. Same feature for Character
name.
** The issue pulldown for navigation (and next/prev) and the
hyperlinks on the series and publisher are great!
* ONLINE INDEXING
** Just a general comment that I think has been discused before. The
ability to provide "suggestions" and to recall other data would be
very helpful in making the data entry process quicker and less error
prone. For example, being able to replicate credits from the previous
issue for ongoing series. Also if the ultimate goal is to be able to
index all the pages in a book, I'd think having a way to pull up the
information that is repeated between books would be useful, eg: the
monthly editorial pages, or the preview stories - there should be a
way to select a master record and auto add that to the entry. I'm
sure this has come up in the indexing of collections/reprints as well.
** Also having different data fields for different sequence types
might also make data entry easier, eg: for Ads, Editorials etc which
may not need all the data associated with a story.
** Finally auto-checking simple issues like typos/spell check,
checking creator's names, checking for extra sem-colons at the end of
the field, valid currency names etc
> INTEGRATION
> ===========
>
> *REST API*
> -----------------
queries
* Query Series Text - returns matching set of series and series id
* Query Series ID - returns series info and set of issue ids for
specified series id
* Query Issue ID - returns issue info including cover urls for
specified issue id
These simple queries could be used to create simple widgets for a web
page to pull creator credits for example
I think this is something where you need to iterate rather than trying
to do a big design up front.
> *Data Integration*
> --------------------------
> This to some degree depends on the API, but we got several good ideas about integrating with things like Diamond previews and other data sources for checking what work we need to do. This will probably produce some pretty straightforward short-term goals.
(http://www.comichron.com/) - just a data-loving type of person :-)
> MOBILE
> ======
> We didn't cover this much except to note that some folks have already started developing apps. I have suggested to one who was in touch with me recently that he should announce his app on gcd-tech as I'm sure folks would like to see it. I'm not sure we need much more on this topic right now.
what you'd want to customize for online access. I suppose one idea
would be to allow a special export (eg: to a sqlite db) for local
mobile access for offline access.
> OTHER
> ======
> Phil's karma point system is worth further discussion. I especially like the idea of being able to commission projects or make requests based on points, which makes it more than just a "hey, I got a new sparkle on my profile" sort of thing. I still need to spend more time writing a response to the original message on this topic.
items for indexers to complete. Nervana might be an automatic
matching based on previous indexes to flag similar items that still
need to be indexed (eg: I indexed a bunch of Avengers titles and a
couple of Avenger issues need indexing) - basically an intelligent
suggestion system. Alternatively a set of reports that show where
indexes are needed, eg: series "completeness" so that we can easily
spot those series that have just a few holes (or alternatively those
that have huge holes so we can index a nice juicy run).
Henry Andrews
I'll come back to this and we'll drive this process to conclusion as soon as things settle down, but it's a very busy time of year.
thanks,
-henry
----- Original Message ----
> From: PhilR <philip....@gmail.com>
> To: gcd-software-committee <gcd-softwar...@googlegroups.com>
> Sent: Mon, June 14, 2010 8:26:43 PM
> Subject: [gcd-software] Re: The story so far...
>
> I've been tweaking this response, adding in items as I think of them
for the
> past week... and here it is...
On Jun 8, 2:06 am, Henry Andrews <
> ymailto="mailto:h...@cornell.edu"