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

Comments (43)

1 localhost commented Trackback

The only issue the others haven't already covered (unless I missed it) is whether there's any chance of having the indicator automatically expand when the users is within a certain percentage of their quota. So, when the bar turns red, can we make the control auto-expand when the user opens their mail file? Otherwise they'll close it to get back the screen real estate, then never look again.

2 localhost commented Trackback

1. I think it depends... First and foremost, on the impact to the user experience - will it add significant time to the replication? Then, I would think that if the space used is below a certain threshold, I wouldn't really care, but it it gets close to a critical limit, I would like to have closer monitoring.

2. I'm not sure the server name would be very useful. And then what would happen if you worked with a local replica? Would it just say "local"?
3. No. I think it's a good idea for users to see this information.
4. I like the control all the time. However, if a quota is not established, perhaps just displaying the amount of space currently used instead.

3 localhost commented Trackback

1. Could the refresh be linked to the warning threshold, below it long periods between refreshes would be fine, however about it you need to keep the user informed.

2. Rather than the server name, maybe it just state that the replica is on a server, most users get confused by server names, but if it says Server Copy or Local Copy they should understand that.
3. I think Admins should be able to control when it's displayed, eg. optional by default, but force it to display if the warning threshold is exceeded.
4. Displaying locally gives issues as obviously file sizes can vary between file systems or if the local replica has got few view indexes built it will display significantly smaller.
Overall a very useful feature.

4 localhost commented Permalink

The right answer is simple, but hard to execute.

Whenever the user looks at the quota indicator, it should be correct. Period. This will probably require frequent polling for whenever the user receives new mail. For people who are replicating rather than local, you can hold off until just after each replication. But, for people who are reading their mail on the server, it should update at least as frequently as the "new mail" indicator does.

5 localhost commented Permalink

I agree with Brian on the update frequency - furthermore, I think it should be updated when the user deletes documents from their mailfile as well - just to get that immediate feedback when our conscientious users do their housekeeping :)

6 localhost commented Permalink

1. Refresh as often as reasonable without negative impact on performance. When a user is trying to get their mailfile back under quota, they'll look at this, so it needs to reflect the correct size. I agree with those who said it would be nice if this refreshed more often when close to the limit. Otherwise, perhaps a refresh indicator/button. Definitely should refresh on replication if possible. Could we put a 'compact' button there, too?

2. If you're going to show the server name there, then yes it should collapse with the quota bar. But I agree that I wouldn't choose to have the server name there. That's something my users do not need to know most of the time.
3. Yes to controlled via Admin policy. Some people/companies will want it, and others will not.
4. I would want it displayed even on a local replica. We have a large number of users who travel and only ever work off a local replica.

7 localhost commented Permalink

3. Yes. I don't understand the first comment, above; policies mean the admin controls whether it's displayed. Almost everything should be controllable via policy.

BTW, I like the ideas mentioned above, of showing the mail file size even if we don't use quotas. (Just don't show the bar if there's no quota.) So instead of "3% of 5 GB" it would say something like "150 MB" to indicate the absolute amount of space the mail file takes up.

8 localhost commented Permalink

It should be controlled via Admin policy, so, for example, administrator can configure it to show by default if the warning level has been reached; and to hide by defrault if the warning level has not been reached.

9 localhost commented Permalink

@Maria and @Charles

the compact button is a good idea but when using transactional logging, the user can't compact his own mailfile so it's useless in that case.

10 localhost commented Permalink

Since this is a feature for the end user and the end user doesn't understand or care about compacting the database (nor should they), the size displayed should be based on the actual used size. The mail template where I work has custom indicator similar to what is being proposed. A regular cause of users exclaiming "Notes is S**t!" is when they delete a bunch of mails and the used space does not go down. A few will listen to why this is and that the database will be compacted overnight and everything will be ok in the morning. The rest will just complain endlessly.

11 localhost commented Permalink

1. Slight correction to what Brian said: if it's shown it has to be correct. If the DB changed and the new size hasn't been calculated don't show a value but maybe a comment that says "click to update graph/value".

2. The expand marker looks like a scroll-down button on some sidebars. And if you know it's a expand button there is no hint what's hidden. Make the graph smaller so numbers and graph fit on one line, small enough to show always.
4. If I use a local replica I'm still interested in the servers replica size/quota: this is the limit I need to take care off.

12 localhost commented Trackback

@Totally agree with Kerr

The "used space" value should always work with a virtual database size, how big the database would be if it were compacted.(And this size is very easy to get: DB.Size * DB.PercentUsed / 100 )As already mentioned the user should not care about compacting, nor does he have always the rights and nor do i want a compact to be done during working hours if it can happen during the night.If he deletes 100 documents, he wants to see IMMEDIATELY how this affected his used quota.(And what he definitely not wants is: delete docs, compact (and wait), update graph to see the impact, delete some other docs, compact, update graph, ...)
This reminds me of a connected problem: Local replicas and compactIf someone has many local replicas they tend to grow in size because no user performs a manual compact on them. (As it is quite time consuming to go through 100 dbs and trigger a compact) We need therefore in the client a function "COMPACT ALL LOCAL DATABASES". Eventually this action might even be scheduled, so that admins can set it up for the users and they need not to care anymore.

13 localhost commented Permalink

It's unfortunate that "nice to have" features end up taking away more and more screen real estate. Personally I would prefer to preserve the space in this frame for displaying the folders I am working with (and wanting to drag messages into). While the collapsed control is fine, there isn't really any alert that a user can react to if the control is collapsed until the quota is hit. Why not develop an mail file icon that sits beside beside the mail box name. It would sit there as a static (green?) icon that changes behaviour (yellow = caution, slow flashing red = attention required) as events or thresholds are passed that a user can manage or react to. Clicking on the icon would open up the quota control, and potentially over controls, that require attention. Server names could then be displayed in the control aligned the specific alert.

14 localhost commented Permalink

I agree with most of the comments here. I don't think it should be hideable. I think it should always display or people will ignore it. And it should definitely display in the local, but it should reflect what's on the server. So maybe instead of having the server name at the top then the graph then the numbers, maybe it should be the graph, then the numbers then "on [ServerName]" so that it was clear that it's the size of your server replica and not the size of your local replica. Just my $0.02.


15 localhost commented Permalink

1. Refresh should happen fairly often. I think the refresh on every replication cycle would be good, but perhaps giving options on frequency would be better.

2. I dont think server name would be that that useful for the general populous.
3. Admin policy for this would be nice, but I would assume that most users/sys admins would want this by default.
4. This should be in all mail files regardless of location. That way if people work locally or on the server they will be aware of their mail file size.

Add a Comment Add a Comment