[ADV] Rails Recipes Beta Book is now available

On Feb 4, 2006, at 16:12, Dave T. wrote:

The ‘reported in’ field is the version of the book that is know to
contain the error, and the ‘fixed in’ field is the version that
contains the fix.

So, if you previously had (say) P1.2, and you want to know what’s
different in the very latest version, select P1.2 in the drop-down
list at the top of the page, and view all the errata marked as
‘fixed’.

Certainly, I didn’t understand the three labels in the header of the
column corresponded to three potential entries in the same cell. I
was confused by the header. When I have had a glance at that page I
have not noticed that most cells have one line, but some more, and
that has to do with the header. Now that I see it I understand it,
but I honestly think the usability of the interface needs a revision.

Why did you do this instead of having just three standard columns and
one bit of information per cell, as usual? I believe that would be
more obvious. In addition, I think it would be really useful for the
reader to offer an additional simple page “new stuff on this
revision” that presents only that.

– fxn

Alain R. wrote:
> Currently, everything is mixed up -errors, typos, suggestions
etc…-

and it’s 25 page long.

I just need the errors, typos and improvements.
=> a simple configurable filter would already be a great help.

Alain

On Feb 4, 2006, at 18:28, Xavier N. wrote:

Certainly, I didn’t understand the three labels in the header of
the column corresponded to three potential entries in the same
cell. I was confused by the header. When I have had a glance at
that page I have not noticed that most cells have one line, but
some more, and that has to do with the header. Now that I see it I
understand it, but I honestly think the usability of the interface
needs a revision.

I forgot to mention that there’s not even a correspondence with three
lines in the cell, because at least in my browser the lines wrap:

 http://www.hashref.com/img/agile_errata.png

Nah, I think that column needs a split.

– fxn

Chad
> You will receive emails when updates are available, so you don’t
need
> to continue to go back to the site.

When the next version is available, please make it clear what’s been -
seriously - changed and needs to be reprinted.

Alain

On 2/3/06, NexusNeo - Niket P. [email protected] wrote:

Purchased Book and downloaded.
But just curious that will any update i will receive automatically to my
email or need to check web site regularly?
This is the first book I’m purcashed under beta programme so curious.

Hi and thanks!

You will receive emails when updates are available, so you don’t need
to continue to go back to the site.

I hope you enjoy and benefit from the book!


Chad F.
http://chadfowler.com
http://pragmaticprogrammer.com/titles/fr_rr/ (Rails Recipes - In Beta!)
http://pragmaticprogrammer.com/titles/mjwti/ (My Job Went to India,
and All I Got Was This Lousy Book)
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over one million gems served!)

On Feb 4, 2006, at 10:50 AM, Alain R. wrote:

Dave

Tell me what’s needed, and I’ll look into it.

There should be a simple way to print a clean - long - page with
all the changes that apply to a pdf version.
Currently, everything is mixed up -errors, typos, suggestions
etc…- and the last column is cryptic and confusing (fixed In,
fixed On).

I can definitely fix the last column: I was trying to save space, but
it’s easy to split it.

Would it be useful to be able to list by type: error, typo, etc? If
they’ve been marked as fixed, they all correspond to changes in the
book. Are you interested in changes, or just in errors? (If the
latter, I can easily add filters to the list)

I really want to get this right, so all suggestions are gratefully
received.

Dave

Dave
> I can definitely fix the last column: I was trying to save space,
but
> it’s easy to split it.

I think you could simplify the whole screen by 1/adding a 2nd filter,
2/ removing most of the last column, 3/chosing better defaults and
4/using a print.css.

1/ add a 2nd filter :

fllter 1: “select your current copy”
filter 2: “display changes since or after …”

2/
=> in the last column, just display the "fixed in’ version number;
(it’s enough now, thanks to the new filter).

Would it be useful to be able to list by type: error, typo, etc? If
they’ve been marked as fixed, they all correspond to changes in the
book. Are you interested in changes, or just in errors? (If the latter,
I can easily add filters to the list)

3/ better default
By default, you should only display what’s needed to keep an old copy up
to date with the latest pdf version
=> hide "suggestions, non-problems, …)

Seeing “suggestions” should be one click-farther.

4/
Another suggestion: if it’s possible, remove the “show printable
version” button and use css instead. I only recently noticed the button
because I was not looking for it.
(I always preview before printing, to see the pages I can trim. If
it’s no good for printing, I change the css with Firefox + WebDeveloper,
to hide sidebars, logos, adsense, etc…)

Alain

On Feb 4, 2006, at 12:47 PM, Alain R. wrote:

Dave

I can definitely fix the last column: I was trying to save
space, but
it’s easy to split it.

I think you could simplify the whole screen by 1/adding a 2nd
filter, 2/ removing most of the last column, 3/chosing better
defaults and 4/using a print.css.

Is browser support for print CSS’s universal enough now? If so, I’ll
switch.

1/ add a 2nd filter :

fllter 1: “select your current copy”
filter 2: “display changes since or after …”

I must be misunderstanding, because I’m not sure I see the difference
between these: aren’t you effectively interested in the changes since
you last applied changes? If you remember to change the page at the
front containing the printing, then the changes will correspond to
the copy.

3/ better default
By default, you should only display what’s needed to keep an old
copy up to date with the latest pdf version
=> hide "suggestions, non-problems, …)

But suggestions also result in changes to the content if they’re
accepted.

Here’s a thought, though. Right now, I show both open errata and
fixed errata on the same page. Perhaps what I want is a totally
separate “change sheet” where you say:

  • list all the changes that have been accepted and applied to a book
    between version x and version y

That strikes me as being a useful addition, and it seems like it
would give you a lot of what you want. All that would be missing (for
beta books) is the listing of totally new content, and that will
appear on the announcement emails.

Would that new page I’m suggesting work for folks?

On Feb 4, 2006, at 20:04, Dave T. wrote:

  • list all the changes that have been accepted and applied to a
    book between version x and version y

That strikes me as being a useful addition, and it seems like it
would give you a lot of what you want. All that would be missing
(for beta books) is the listing of totally new content, and that
will appear on the announcement emails.

That’s the one I want.

I guess you mean this, but just in case, I don’t care about whether
the fix was proposed and accepted, or independently discovered by the
author. I only care about applied changes not mentioned in the
announcement mail.

– fxn

Typically you get an email telling you a new version of the beta book
is available for download.

Dave

> Is browser support for print CSS's universal enough now? If so, 

I’ll
> switch.

I’ve googled but I couldn’t find any mention of a browser support
problem with
media=“print”
.

>>  filter 2: "display changes since or after .."
> I must be misunderstanding, because I'm not sure I see the

difference …

You’re right.
I badly wanted to unbloat the latest column and only keep the fixed_in
version number.
There’s no simple nor elegant way with the current all-in-one page
design.

>> 3/ better default
>> By default, you should only display what's needed to keep an old

copy
>> up to date with the latest pdf version
>> => hide "suggestions, non-problems, …)
>
> But suggestions also result in changes to the content if they’re
accepted.

I suspect most of the people who access the errata page are only reading
it, not writing.
The defaults should be chosen for this majority.

> Here's a thought, though....
 >
> - list all the changes that have been accepted and applied to a 

book
> between version x and version y

> Would that new page I’m suggesting work for folks?

Yep.
It’s exactly what I - thought I - was asking: a clean and easy way to 1/
see how obsolete my copy is, and 2/ to print a diff list.

Alain

On 2/4/06, Dave T. [email protected] wrote:

  • list all the changes that have been accepted and applied to a book
    between version x and version y

That strikes me as being a useful addition, and it seems like it
would give you a lot of what you want. All that would be missing (for
beta books) is the listing of totally new content, and that will
appear on the announcement emails.

Would that new page I’m suggesting work for folks?

Yesyesyesyesyesyes. :slight_smile:

On Feb 4, 2006, at 2:53 PM, Alain R. wrote:

I suspect most of the people who access the errata page are only
reading it, not writing.
The defaults should be chosen for this majority.

But… the report of an errata doesn’t mean it has been accepted as
such by the author. Therefore, if you want to update your book, you
should only use things that have been accepted: that means they’ve
made their way into the book. Suggestions, typos, and so on all
therefore are reflected in changes, but only after they’ve been
accepted.

Here’s the information I carry around for each erratum:

  • when it was created
  • who created it
  • the release of the book the reporter found the problem in
  • the PDF and paper page numbers
  • the description
  • the type (suggestion, typo, etc…)
  • the date the author fixed the book (or null)
  • the release of the book the author fixed the problem in (or null)

So, I’d like some help:

First: what would be a good format for listings in the main errata
page? I want to show all errata pertinent to a particular release (as
now).

Second: what should be a good UI to allow folks to create the "list
of changes to apply to my book) listing.

I guess I’m asking: one page, or two. And what should it/they look like.

If people would like to comp some stuff up, it might be an idea to
post to a server, then link from this list.

Thanks for all the feedback.

Dave

On Sat, 04 Feb 2006 13:04:47 -0600, Dave T. wrote:

Perhaps what I want is a totally
separate “change sheet” where you say:

  • list all the changes that have been accepted and applied to a book
    between version x and version y

Yes, that’d be wonderful! And, I presume, its inverse would be useful
to
authors, if they don’t already get such a report…

Jay L.