At least for #2, you can fix that in Firefox by setting browser.tabs.drawInTitlebar to false in about:config.
I'm with you. My pet peeve with Google Docs is that the page randomly scrolls to different parts of the doc while I'm editing--and not due to anyone else editing.
Web apps are awful, and I'm saying this as a professional author of them. Maybe in another 5 years, we'll be back where we were in 1984, UI-wise. With an infrastructure that wasn't designed to handle them, web apps are also harder to write than desktop ones. Their one saving grace is that you don't have to go around porting or installing them, which can be significant in a cross-platform environment. As for me, my UI Nazi tendencies keep me on local apps whenever possible. See http://www.subethaedit.net/ for how apps ought to be.
The author, Erik Rose works at Penn State University, supporting many educational Plone websites. So his credentials for writing the book are OK.
Target audience: well, you want a website for your course or your university department or your group of teachers. You're able to get your hands on a webserver where you can install Plone. You want multiple people to be able to comfortably update the site without getting stuck on a single webmaster. The book's subtitle rightfully is break the webmaster bottleneck by empowering instructors and staff. You can set up a reliable, functional and professional website yourself without needing to pay tens of thousands of Dollars/Euros/whatever in license fees. You'll need to know about websites in general and you'll need to be reasonably comfortable installing stuff on your own PC and, possibly/probably with someone's help, on a webserver.
Non-educational audiences can get benefit from the book, too. A results-oriented intro on skinning/theming doesn't hurt a small business website. And the calendaring tips are also useful for a church or sports club website. You might want to look up the online table of contents.
Book style: perhaps strange for a technical book, but I'd say it makes you enthousiastic. It shows you how to accomplish things with Plone. How to get specific things things done, as the book is laced with screenshots ("this is what your course page can look like") and direction-giving introductions ("you'll probably need a staff directory, here's what you can accomplish"). The tone is friendly, but with experience-born firmness and personal opinion in some cases.
Overall book impression is very positive. For a technical book it is mercifully thin at some 190 pages compared to the customary 300. Yet it is remarkably complete. You get to set up your site with content, tips on essential add-on products, skinning/theming basics, web server installation and setup instructions and basic maintenance (backup/restore) guidelines. All the basics you really need. If you need more, there are other books.
For more elaborate theming you could pick up Veda William's Plone 3 Theming book and for hard-core development Martin Aspeli's Professional Plone Development.
The first chapter shows you how to get most of the information you need to present for a course done with out-of-the-box Plone. A couple of folders, events for exam dates, agenda items for homework and assignments, some overview pages. And practical advice, for instance on enabling comments: they help invite feedback and increase interaction between students. And with the proper settings, comment spam is virtually non-existant. The chapter has effective screenshots that show what you can accomplish and how to do it. The screenshots are especially handy for Plone's powerful collections ("smart folders" that effectively show search results) as they can be tricky to configure. A screenshot helps a lot in explaining the necessary settings.
The second chapter helps you install the first add-on product with reasonably complete instructions. The add-on helps you show your date and event related information in prettier ways than is possible with stock Plone. The chapter has some side comment on security (group/user rights) setup which deserved a more prominent spot. But where... The book is full of small helpful tips and information, so perhaps such "oh, by the way" sidebars are ok. Also good: the author is not afraid of pinpointing Plone pain points: in this case spotty support for showing recurrences.
A university or school needs a list of faculty/staff. The author and his colleages wrote a specific add-on for this purpose and documented it fully in chapter three. A-z listings, per-department views, per-speciality views. Handy is the documentation on how to best use the various grouping methods (department, speciality, group) and how to connect the staff in this listing with their actual login accounts.
But... every university is different and wants extra fields: a fax number, a building floor, a list of published papers. Plone allows you to extend existing products in a reasonably clean way and chapter 4 shows you how. Watch out, though, as the instructions on how to set up a new site to test your extension misses several steps and uses a program which full installation instructions are only explained in chapter eight. One of the rare real omissions in the book.
Chapter five helps you add blog and forum functionality. There are several add-ons for that. Add-ons mean extra functionality but also extra risk: how well are they maintained? The author helps you with criteria and gives you his own recommendation. Most of the time I agree, but I was a bit surprised at the "PloneBoard" add-on's description of recieving prompt updates all the time: two or three years ago it was a problem child with a poor maintainance record as far as I could see at the time. So take a good look at the current maintenance record of add-ons!
Chapter six has one of those attention-grabbing sentences in the introduction that invite you to really delve into the chapter: "triple your traffic using the iTunes store". And yes, later on it helps you set up podcasting for your audio or video lecture notes with Plone and submit the podcast to iTunes. Which apparently triples the incoming traffic for many educational institutions.
A Plone killer feature is introduced in chapter seven. PloneFormMailer is a fantastic add-on for creating forms without resorting to programming. Almost all sites I deployed when working as a full-time Plone programmer included PloneFormMailer. The author heaps praise on this add-on and he's right. Good point for the book: it shows all the available form field types as small screenshots. That helps when building the forms.
Chapter eight is on theming/skinning/styling your Plone site. Theming is a bit of a pain point in Plone right now. Plone is halfway the easier, but sloppier and harder to debug Plone 2 style of skinning and some incredible (I mean that!) probably-there-in-a-year Plone 5 goodness. And being halfway means confusion, so this is a difficult chapter for a book author. In my opinion, the author has done a good job explaining all the necessary ingredients and the various ways in which you can get your hands on some necessary adjustments of Plone's default style to your organisation's style.
Chapter nine made me say "wow". A solid chapter on deploying your site on the server. Including apache and squid setup and a Plone caching tutorial. Yes, your site needs to be able to stand up agains a whole flock of students hitting your site right after class (or five minutes before the final exam). For educational settings, the tip to look at Enfold proxy to integrate with Windows' IIS server is a good one. One thing that surprised me was to see Squid as a caching proxy: I thought Varnish was the standard by now. At least, it's been at least two years since I last touched Squid.
The last chapter, ten, finishes off the book with some maintentance tasks like backups. Good chapter for yourself or your sysadmin.
All in all: recommended!"
Link to Original Source
You bring up an excellent point: ZODB doesn't do any referential or data-type integrity checking; it's pretty much just a dumb (though rather concurrent and durable) graph store. Thus, ZODB-using apps have to take care of data integrity themselves or else interpose another layer (which you'd want to do in a "shared" situation like you mention).
I guess that's the tradeoff ZODB makes: really fast and agile development (no schemas to maintain, etc.) in exchange for no particular constraint enforcement. In practice, the latter is mitigated (and lots of painful debugging saved) through use of constraint-enforcement frameworks like Archetypes, but that still makes me queasy in a multi-app situation, as you'd have to make sure everybody uses the framework.
Personally, I'm both a ZODB and a Postgres wonk. What I'd love to see is the best of both worlds: a language-agnostic graph DB with internal constraint enforcement and, as my pony, a declarative ad hoc querying language.
To be fair, I wouldn't say the Zope database (ZODB) is not a "solid foundation". It's one of the best parts of the Zope stack and, in 3 years of dozens of clients using it in Zenoss, Plone, and other apps, I've never had it corrupt or lose any data. It's a proper DB--ACID, MVCC, and all that--and you can even lop transactions off the storage to go back in time. Don't expect it to be a relational DB with the ad hoc query tools typical thereof; it's an object DB, with the aim of persisting graphs of Python objects transparently.
Now, if you aren't familiar with it, the ZODB can indeed seem opaque, but, just like any DB, there are tools to read and modify it. At the highest level, just stick "manage" after your Zenoss URL, e.g. http://example.com/zport/dmd/manage . That'll get you into the web-based Zope Management Interface (colloquially, "the ZMI"), where you can poke around at any object that someone's bothered to write a UI for. Deeper than that, you can connect to ZEO (a server that brokers access to the ZODB over a socket) and mess with the object graph using normal Python. When you're done, "import transaction; transaction.commit()". (The Zenoss developers are probably trying to scare you away from such digging around in fear that you'll violate their objects' invariants and leave them a real mess to solve.)
Now, I don't say that Zope isn't scary; it has over 10 years of scary stored up in it. But the ZODB is a cuddly, loving part.
I should mention that we use a ticketing system (Trac) for more involved stuff, but IRC is great for quick or rapid-fire-interactive requests.