Closed spyysalo closed 13 years ago
Suggesting that we show the text in a text box to the right in the file browser. We have plenty of horizontal space anyway and this data would just go into the getDirectoryInformation
action response.
OK with this implementation, please go ahead :-)
Here's an example README
Sample Data for BioNLP Shared Task 2011 Main Task
Epigenetics and Post-translational Modifications (EpiPTM)
- Contains 12 PubMed abstracts and their annotations.
- For format details, please refer to the shared task homepage.
http://sites.google.com/site/bionlpst/
File Descriptions:
*.txt files contain the target text.
Each of these files consists of two lines, one for the title and
one for the abstract.
*.a1 files contain standoff annotations for Proteins entities.
*.a2 files contain standoff annotations for other entities and events.
For training, the participants will be provided with these files.
For test, the participants have to create this annotation.
History:
14 Sep 2010: third revision released.
27 Aug 2010: second revision released.
25 Aug 2010: first revision released.
23 Aug 2010: initial version released.
Authors:
BioNLP Shared Task 2011 organizers,
bionlp-st@googlegroups.com
http://sites.google.com/site/bionlpst/
... OK, that didn't make any sense.
We'll need to send that from the server. I'll do this.
Server side, done, the client now gets description
as part of getCollectionInformation
response, value null
if README is absent (or cannot be read) and full text content of README if found in directory.
Handing over to @amadanmath.
Actually, it might make more sense to do this using (an extension of) the pre-existing messaging protocol instead of introducing an exceptional case. If the message interface had a flag for display style allowing messages to be shown in a larger, centered (possibly modal?) dialog instead of just as the small screen-bottom entries, then this should be enough to implement the README display.
@spyysalo: I think embedding it in getCollectionInformation
is a cleaner solution. I generally dislike the messaging protocol since it forces visual aspects and client behaviour to the server.
@spyysalo: I think embedding it in getCollectionInformation
is a cleaner solution. I generally dislike the messaging protocol since it forces visual aspects and client behaviour to the server. The only times when it should be used is really when the client has no way of presenting all the details regarding, say, an error and we need to send a large chunk of raw text to the client.
It might be a good idea to send the description
with the search results as well, so as to describe the search criteria that produced the collection. What do you think?
Actually, I find it a bit strange that the "Collection information" part is present at all in the search results. Other opinions?
@spyysalo: Well I'd say it feels odd that it goes on top, since it sometimes is there and sometimes it is not. If it goes there we should have a filler if it is not present or put it in a place that doesn't move around the actual file browsing portion if it is present.
@ninjin: yeah, I agree that the current integration into the UI is pretty bad. I was thinking about this a bit actually; how about having a convention where the first line of the README is expected to be a brief description, just displaying that normally, and having a "More..." button to the right?
That is, something like this:
(with "More ..." instead of "Cancel" on the button, of course.)
Afterthought: the "Collection information" frame should probably merge somehow with the "Collection" frame in the layout.
@spyysalo: I like the suggestion of being able to expand it. Then we can simply put "No collection information available" if there is no README.
The original issue is now addressed; opened #451 for the remaining tweaks, closing this.
Suggestion from user: we're starting to have quite a lot of corpora in various installations and it's not always easy to remember what's what. We could help alleviate this issue by having the tool display a README file (if found) when first navigating to a new directory.