• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (31)

1 localhost commented Trackback

I would say: do not increase complexity now in anticipation of decreasing it later.

No one who deploys Notes applications in the real world today expects users to do it themselves. They send emails, use corporate bookmarks, use policys, or write custom installation routines. They do NOT wait for users to click Ctrl+O and go exploring.
You don't need to solve this right now. Leave them off. Let administrators and developers manage the deployment issues via other tools, and don't worry about making it discoverable to users until you can do it properly -- through a central integrated catalog of applications that make it easy for a customer to front-end via roles. That's all stuff for WPE and Connections implementations.

2 localhost commented Permalink

I agree with Nathan above.

One idea, if you want users to add Eclipse apps could be to keep all your new application menus (keeping it simple) above. However, when you get to the next menu (I have Notes 7.X which shows the Server field/list of local database) the Server field allows you to browse not only to a Domino server but to some Eclipse server (however it's deployed) as well. In theory, it could also allow you to open an 'application' on a web server as well...which would really just browse to it using Notes.
Therefore you treat Notes and Eclipse stuff all as 'applications' and keep the model nice and simple for users.

3 localhost commented Permalink

As an SMB I have to disagree with Nathan. Having an adhoc method and not relying on anyone else to push anything out is a big plus in smaller orgs.

The appeal of the eclipse plug-ins is in it being dynamic based on an individuals choice and not being constrained by the IT folks. If this great new feature can't be easily accessible I'm concerned it will never get the momentum it should.
If I want to show someone how an new plug-in benefits our company I have to first get someone else to push it out via policies or whatever - before I can even get it installed to check it out for evaluation? That's backwards to what this feature is about.
I understand where Nathan is coming from but removing it isn't an option IMO. I repeat - not an option to hide this :)
Darryl's suggestion seems like a prudent one.

4 localhost commented Trackback

Offhand I cannot remember exactly who Samantha is except that she is an AA (I know, you blogged about the persona's, but I'm too busy -- lazy? -- to find it). Anyway, the point is, do you really think that Samantha is going to even pay attention to these menu options, let alone figure out what they are and how to use them? After all, if users are "scared" of the term Database, I can assure you that the term "Application" and the menu options "Install Applications" and "Manage Applications" when they are IN an application will scare them just the same. "What does it mean to install an application in Notes? What happens if I do that?" They will freak! You and I and almost everyone reading your blog understands what Eclipse is and how this all works, but Samantha does not understand and giving her the option to install applications/plug-ins/features assumes that she does understand, at least to a degree.

I don't think the terminology is all that important here, though I will say that I think "plug-in" is more of an accepted term. What I think the real question you should be asking is whether or not you should be surfacing this type of feature to all users. Most of the users I deal with are already scared of the wealth of options available in Notes menus. They are gigantic! Depending on your resolution some take up the entire height of the screen! Throw a few more at them and they're heads just might explode. Might I suggest considering the ability to install/manage applications/plug-ins/what-have-you is not up for debate, it will need to be there, but not for all users. Organizations will want to be able to display different menu sets to different users. Basic menus, Advanced menus, Administration menus, Development menus, etc. In most cases I would bet that Samantha does not need -- or even want! -- to install plug-ins herself, but would rather have a basic set of menu functions pared down to her most basic needs: read/send email, accept/decline/create calendar entries, etc. Her Domino admins can push new plug-ins down to her when the organization deploys the hot new whizbang app for AA's.
On a side note, since you mentioned it, I really do not like the term Application in place of Database. I can't really say why except that I'll have to change all my documentation and screen shots, but that's not the problem. I really don't know what it is. Maybe I'm too stuck in my old Notes ways. :-)

5 localhost commented Trackback

- To replace "database" with "application" is quite a huge step, but i guess that is still OK, because it will be more understandable for end-users.

- Yes you can add the two menu items to the "Application"-submenu. For developers, administrators and powerusers this will be nice and they can understand this.
However you should consider that all the other "ordinary users" will not need it. And even worse it will confuse them (as the menu already does now) if they accidentally open it.The standard user never opens databases on his own. He does not need an option like "Refresh Design","New Copy", "Show ACL" (he actually does not need the whole "Application" - submenu)He would be most satisfied if all these advanced options were GONE and his client would appear more simple so he could focus on the functions he really uses.(He does not need any "Replication"-menu and replicator page as well if he uses only a desktop)
Ideally all these "advanced" menu options should be hideable through policies ao that the administrator could decide who nedd what. But i guess that is an other discussion ...

6 localhost commented Permalink

I guess I need an example: what 'applications' or 'features' will Samantha be installing? And how would she know to go to an Applications menu to install features? Ah, you already admit she won't understand these. Then why mix two different beasts into one menu when they're different and she won't get it anyway? I feel this kind of faux simplification just complicates things. Make a Plug-In item below Applications; don't add them TO the Applications menu.

"I can't install the application you sent me" "Don't install it, just click the link...those menu options are for Eclipse plug-ins" "What's a plug-in?!" "Just ignore those menu options!" Etc. ;-)
But, again, I think I need an example; I'm curious what features a user might think they'd add to my Notes application.... (Obviously I haven't used Eclipse much and we don't use SameTime 7.5.)

7 localhost commented Trackback

Whether it is called applications or databases doesn't really matter to me though I find that most users already think of databases being applications anyway so you might as well change it. Going to Notes 8 and it being a major version is as good a time as any.

As to the whole installing/managing debacle I must say that I'm torn. As a developer I would prefer having the options there but if I put on my administrator cap I must agree with Nathan (first comment). No users understands what a database actually is and how to open it. I never met an user that actually pressed Ctrl-O themselves. What if an "application" is made up of 9 databases. Which one should he open? It is my opinion that applications are best deployed by an IT person or using other means such as policies, bookmarks etc.
That being said I still find it very interesting to have a menu option for installing, what is in fact, Eclipse plug-ins. To make matters worse, as some might know, you do not install plug-ins in Eclipse but you install features which in turn contains plug-ins (and optionally fragments). I really do not want to have users starting to refer to "plug-ins" when they in fact mean "features" (in Eclipse speak). Do not assign more than one meaning to the same words - kudos to Chris Aniszczyk for clearly stating that above.
In my opinion most users when installing "plug-ins", and let us cater for the majority, will be installing applications that goes in the side-shelf (that is a miniApp aka ViewPart). I can really see the benefit in having users add/remove this kind of applications as they see fit and I think it will be the kind of "application" users will be installing themselves. How they find these side-shelf applications and pick and choose is another matter and require someone more UI/usability savy than me to decide.
I really would not like my users to start installing code that consume extension points that modify menus or similar - those parts I would like to control centrally.
Then what word do we use? Well how about simply "side-shelf application" or "widget"? The latter of these terms are already used in other operating systems or UI applications. "Side-shelf application" would be my choice since it is Notes-specific.
This is off cause only applicable if side-shelf applications is the only type of "application" that an user can install using this menu option. I'm afraid it also opens the whole "which kinds of extensions do we allow the user to make" discussion.
Interesting discussion...

8 localhost commented Trackback


Things seem to be getting more complex and hard to understand, not simpler :(
Mostly I agree with Nathan, though Stephen Hood's point is a good one.
I think you should rethink from a deeper level. Since 'database' is changing to 'application' anyway, now might be the time to adapt to a more 'user headspace' model of how these bits of code and data are contained and moved.
I think people can appreciate the difference between code and data, and sometimes the difference between local and server-based; but no user really cares about the differences between an application and a plugin; nor that that between an application and a design; nor that between 'installing' and 'managing'. All these distinctions merely confuse imo.
(as does, I suspect, that between 'security' and 'composite security' btw)
code / datalocal / server
and no more, are the components of the model I think you should provide through the UI.
I can see that you may need to make only incremental changes before the pub beta, but a deeper rethink -- of only of terms and menu positioning -- might be wise for the following one. Sorry to be a dog in the manger. ;)

9 localhost commented Permalink

Is it too late for me to suggest a few different versions of the Lotus Notes Client:

a) Email client only (for the dummies that still think that Notes is only used for email)
b) Basic client (with simplified options) allowing email and basic groupware applications (e.g. existing Notes applications)
c) Advanced client (with all standard Notes features) for mobile users.
e) Advanced client (with Eclipse) and plugins +++ etc.
As I understand it, c & d are what is currently available, but rather than hobble the Notes Client for power users or other people who have been using the Notes client since Ray Ozzie was still considered a blond, why not consider some simplified versions that focus on simplicity and ease of use.

10 localhost commented Permalink

This is really a techie question, and i'd think a better user oriented question would be "do users have to worry about eclipse plugins at all" ?

What's the relation (if any) between user experience and eclispe plug-ins ?

11 localhost commented Permalink

When we use a browser, we go to lots of different 'sites' which may behave very differently. In Firefox, user's can also install plug-ins which change the way we interact with sites (handle tabs differently, change the appearance, display special content types, etc), but these are site independant.

In Excel, you open a workbook, which can be formatted differntly, have varying levels of coding etc. You install add-ons which are available for all workbooks.
I know these distinctions are somewhat blurred with the new mix of Notes apps, composite apps & Eclipse plug-ins, but I would try to use the same approach: you open, bookmark, work with then close an application or database. If you install a plug-in, this is something that stays in your client until it is un-installed.
So my preference would be:
File - Open ---> leads to the File-Database-Open dialog. I notice your screenshot has a pull-right for this menu. I don't know what's on it, but find somewhere else for them.
File - Application --> things that apply to the currently open application / database such as properties, ACL, New Copy, Delete. New should move from this menu to the bottom of the File - New menu (ideally with Admin / policy control). Design Synopsis only belongs in the Designer. I think Replace Design and Refresh Design should also be restricted to Designer & Admin clients. Archive belongs within an application / database design. Outside the mail file archiving works in many and varied way. And finally Publish ... has anyone *ever* used this? Dump it, or again restrict it to the designer/admin clients.
File - Plug-ins. For consistency with Eclipse & Sametime you could retain the two sub-menus (Download and Configure) but I would like to see these both rolled into the one dialog box, as in Firefox.

12 localhost commented Permalink

I know this is horribly off-topic, but is there any chance that the Trace Ports functionality buried absurdly deep under User Preferences could move / morph into a simple 'Test Connection' button in the address book, or wherever Connection Documents will be defined in future? So that you define a connection & test it in the same place?

13 localhost commented Permalink

I agree with Mary Beth Raven that database is a scary term for end users. Typically users never have to do anything with Database, its generally the IT people who take care of it.

Using common names is greatly appreciated.

14 localhost commented Permalink

Agree that they should be called Applications

I like Michelle's answer (Feb 8 5.48am)

15 localhost commented Permalink

My two cents:

Don't change the wording "Database" to "Application." "Database" has worked for years, why change it now?
Please allow plugins, why even use the Eclipse framework if you aren't even going to allow plugins. The name "plugin" is great because it describes exactly what it is and no one will confuse it with "Database," but they might possibly confuse it with "Application." Another alternative to "plugins," is "extensions" (like in pre-Firefox 2.0).

Add a Comment Add a Comment