I would like to state that Lotus Notes/Domino has been great and I have no intention of changing software. It is essentially the one set of software tools that is responsible for bringing me from poverty and struggling to successful and charming (no exaggeration - I am very charming).
I thought that it would be a worthwhile exercise to compile a list of pet peeves. I do not know which have been addressed already in future versions.
Hopefully this is not against the forum rules and regulations as it will be worthwhile for subsequent notes versions.
I am hoping that this post is popular but doesn’t become a complaint forum.
I have added the first six that came to mind.
Please add to this list or comment in any way you feel to the existing posts …
Subject: #2 Default Error 404 page
#2 Default Error 404 page
Not sure why but there is no on this page. This is not very great for crawlers, link checkers, Search Engine Optimization, best practices and standards, etc.
Solution: I create custom error pages.
Subject: RE: #2 Default Error 404 page
Jeez, that could be because the ACTUAL HTTP FIELDS are being used for status, which is WAY PREFERABLE to trying to set them client-side using tags that the user-agent is not obliged to obey.
Subject: RE: #2 Default Error 404 page
It is nice to have both but fair enough, I agree.
I have been to 404 pages that have neither (non domino pages), hence the post
Al
Subject: RE: #2 Default Error 404 page
The pet peeve I have with the error pages in Domino, is that you cannot run a WebQueryOpen agent on them, as they are considered “special”.
Subject: #6 32K limit for text fields (combined)
#6 32K limit for text fields
The 32K limit for all text fields combined has existed since I can remember. Computers have improved over those years.
I imagine that they have to step through a lot of code to change this but it still seems like a worthwhile change to me.
Solution: use RichText whenever sensible. Store history, metadata or other fields that are not manually modified or often looked at in a separate document. Consider this limit when building your application architecture.
Subject: Lotus/Domino Pet Peeves
Well I should have guessed this would happen.
Please disregard this post.
Thanks for the ideas and input but although I certainly will benefit from it, that wasn’t it’s purpose.
Subject: RE: Lotus/Domino Pet Peeves
A list like this would be so much better on a WIKI where a basic format could be applied;
eg: Headings
Description of Peeve
Status (Resolved, High or Low Priority etc)
How to reproduce this peeve
Workarounds and Alternatives (if any)
Discussion (Pros and Cons)
That way, people could post examples which help others get around problems and you’d be left with a really useful resource.
Subject: RE: Lotus/Domino Pet Peeves
I don’t think this post should/will be disregarded. You’ve brought up points that you have problems with and people are suggesting alternatives/disagreeing/agreeing. That’s what a forum’s there for
Subject: #3 Web Search
#3 Web Search
A sophisticated yet simple search capabilities for the Web would be nice.
Solution: used 3rd party search tools when necessary, use existing LotusScript or Domino search capabilities
- I think something is available in Domino 8.x
Subject: RE: #3 Web Search
Not sure I understand this one. The default search form is basic, but very functional, and it’s not too hard to customize it to look and do much more powerful things with a simple UI. Can you expand on the problem more?
Subject: RE: #3 Web Search
I think the problem here is that Google’s handling of search terms (default OR for tokens with AND results given extra weight in return ranking, and so on) has become the user’s default paradigm. The Google-ese-to-Domino query translator is a simple enough piece of JavaScript, but that relies on the JS-always-on accessibility compromise, and a completely accessible solution (one that requires no site-specific user training) means relying on an agent to do the actual search rather than simply using the built-in search URLs.
Subject: RE: #3 Web Search
For me the problem is sorting and displaying the result in a way of my own choosing.That usually means creating an agent and making my own sorting and/or my own “pretty” output.
Subject: #4 No xhtml
#4 No xhtml
xhtml is great. If it were up to me, every page would be xhtml.
Solution: I create my own xhtml from scratch much like #1 peeve
Subject: RE: #4 No xhtml
That’s a matter of opinion. XHTML is, to my mind, an abomination since it models a document as a generic data container. Did you know that under XHTML, there is no particular reason why a user-agent should display sibling paragraphs in any particular order? HTML, on the other hand, is an SGML dialect designed for the markup of natural language documents.
Oh, and you can always use the outputformat= URL param to force XHTML rendering.
Subject: RE: #4 No xhtml
Not sure I understand.
Anyway, you’re right that is my preference but it is certainly not for everybody.
I am old school. I still use notepad to create html and xhtml that validates and is accessible. I use Firefox with extensions to test. I also am found of dublin core metadata on every page.
In a perfect world, I would use:
xhtml for the container
css for controlling the display
xml for the data
Though using xml for the data might have some SEO issues.
I am not sure I trust your outputformat= suggestion but may try it later.
Subject: RE: #4 No xhtml
Don’t take it personally – I’ve been railing against the wrong-headedness of XHTML hither and yon throughout the internet for quite a while. Simply put: there are structures in natural language documents that cannot be represented properly as XML, and XHTML is a dialect of XML, not of HTML. Things like semantically-significant sibling node order are specifically excluded from the XML DOM, so there is no reasonable expectation that, say, the paragraphs within a chapter of a book represented as an XHTML document ought to appear in any particular order, nor that the chapters themselves should be ordered. (And that really makes no sense when you use an
– by definition, the list items cannot be ordered in XML.)
That does not mean that I don’t want to see well-formed markup, just that XHTML is not the right vehicle to address the problem. HTML is perfectly adequate to the task, and HTML 5 will be more semantically expressive than HTML 4.01. Nor does it mean that I am entirely satisfied with Domino’s HTML output – but that, I think, has more to do with the fundamental difficulty of expressing Rich Text (which is presentation-based) in a semantically meaningful way.
Subject: #1 HTML Validation
#1 HTML
Not much to say here as it is pretty obvious, the HTML doesn’t validate.
Solution: I create my own html and parse out fields from submitted forms as a work around. This defeats the purpose of Domino as the databases essentially become containers and much of the Domino functionality is lost.
Subject: #5 Commas in picklists
#5 Commas in picklists
I found that sometimes commas in picklists get treated as multi-values when rendered in a notes document or the Web.
Solution: Don’t use commas.
Subject: Well this one is poor design by the designer
There is an option on which character to use for multi-value separator, if it’s a field where people could/may enter commas then deselect commas as an option.
But this is your pet peeve so fair enough.