DM,
Just a few notes on the layout; these changes look great, and the table
is definitely easier to read. I do agree that the columns are too narrow.
I was recently looking at this wiki page:
http://en.wikipedia.org/wiki/Comparison_of_web_browsers
The comparison tables on this page look pretty good IMHO, the colors
make the a big difference, making it even easier to discern the
difference between features offered by various frontends.
I looked at how this was done, apparently you can use a simple template
for yes, no etc... so instead of √ you would use {{yes}}. This
would place the text "yes" in the cell with a green background.
Unfortunately I could not figure out how to easily import the {{yes}} /
{{no}} templates into our Wiki, perhaps best left to someone with more
experience. I can try again later tomorrow if nobody gets to it by then
- if you think this is a good idea.
Brian.
DM Smith wrote:
DM Smith wrote:
On Mar 2, 2009, at 8:43 AM, Peter von Kaehne wrote:
Putting data into rows and frontends into columns is so obvious that I
feel now stupid. It is probably too late to fix this for the wiki -
unless you, Eeli, volunteer - the amount has become too much.
I'll see about doing this.
Take a look at the wiki now. I've transposed the first table. I left in
the original, so we can revert easily. Or delete it if we like this
direction.
I thought I'd get feedback before we started making this change.
It probably would have been easier if I printed out the table and then
tried to create the new one. I may have missed something.
I added a row for Testament introductions. These are represented
internally by Book 0, chapter 0, verse 0 for the testament in question.
I used √ because it looks like a check mark. I used ×
because it looked like an X. I can replace these with the images, if we
desire it. I added ½ for partially implemented, but I am not sure
that it is needed. We can always split a feature (e.g. book/chapter
introductions -> book introductions; chapter introductions) or add a
footnote.
I think the X should mean that a feature is missing but ought to be
present.
It is not clear what a blank cell means. In some cases it means that the
feature is a plus but should not be expected in another front end (E.g.
journal in Xiphos). That is, it represents N/A. Some times it means that
it is not know whether a feature is present or not. That is, it
represents ???. I think it is important to minimize maintenance by using
blanks and to call out a program's distinctive/unique features.
A couple of pros about the new layout:
It is easy to add a feature.
It is more compact and perhaps easier to read.
Som cons:
I don't like the abbreviations. So I added a hover/tooltip giving the
full name. (IE allows vertical text and we could do the same with images
of the text.)
The check box columns may be too narrow.
The footnotes are a bear to maintain. I tried adding the wikipedia Cites
package, which as auto numbering. But I did it wrong and it killed the
wiki. I'll try later. For now perhaps we should have footnotes per
front-end rather than per table or wiki page.
Blank cells are ambiguous.
Your input is welcomed. So are your changes to the page!
In Him,
DM
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
