Both, actually. Reading top to bottom mimics the reading view in the review center – which was sensical enough to develop for that audience, and often the same users/personas are developing the artifacts being sent for review. Being able to view the graphics, tables, et cetera inline ... it makes the content read like a document.
The table view which exists is fantastic, as it lets us see a customizable summary and/or report-like views of the data (including the handy custom-color-tinted cells like status), but trying to view specific details of custom rich-text items in our objects is equally invaluable. Perhaps another way of looking at it: table view is best for meetings and reference, reading view is best for detailed reviews and proofreading without having to dive into items or dump their contents to MSWord/Excel.
As an aside to a prior comment in this thread: +1 vote for allowing custom outline numbering. For some reason our templates/QA readers are pretty dependent upon those, and are confused when 6.1.1 becomes 22.214.171.124.1.1. I'm okay with including that value in, e.g., the title field but that's a bit messy on import/export. (low priority nice-to-have IMO)
I strongly agree that this is a very unfortunate shortcoming of an otherwise outstanding product!
My users have a strong preference for the Reading View, given their background with MS Word Requirements documents. But this deficiency is a rather glaring hole.
I have resorted to instructing my users to Copy&Paste important field values into the Description field, so they are visible in the Reading View. (Yuck)
Thanks Jess.Can I confirm that this will apply also to Test Case items?Thanks,
HEADQUARTERS|135 SW Taylor Suite 200, Portland, Oregon, 97204