This might be the wrong StackExchange board to ask this on but, why does the history of an email thread get copied into my reply to that same thread? Is this some historical thing? It seems to be the case that if I delete the history in my reply it has no affect on whether or not it renders properly in the client and no affect on whether or not it gets attached to the right thread. So why does every email client do that?
I believe it is historical, before the days of 'conversation view' which would make the need for the history of the message redundant because it threads all the past related messages together. (It does this via the email subject line.)
However, there are still many people who (a) don't have 'conversation view', or, (b) don't want conversation view. So that is why email clients probably still do this - to compensate for those people who would otherwise have to do a separate search to find the prior messages (really, really annoying). But keeping it there for those who have conversation view is only very mildly annoying - if noticed at all (typically this can be mostly hidden unless you expand it).
Therefore, it still makes good sense from a UX point of view to do this (yes, is this a https://ux.stackexchange.com/ candidate?)
Related
I'm making a simple mmorpg server with IOCP.
I implemented a simple movement function so I tested with dummy clients(also IOCP).
Everything works fine only when few clients are connected. After around 500~1000 clients are connected, some dummy clients occasionally read weird data. I checked that server sends data as I expected but when it comes to dummy clients reading them, they read random data.
My guess is that it could be related to operation system's recv buffer being overflowed but I'm only guessing right now... I have no idea how to check them.
Any suggestion would be very thankful!
The problem with too many WSASends doesn't usually manifest as corrupted data; that's more likely to be a bug in your code. Perhaps your problem is caused by you failing to manage the lifetime of the buffer that is being used to send data correctly? It needs to stay stable until you get the completion for the WSASend call. If you were reusing it sooner than that then you would corrupt the data being sent.
The reason this may show up when you have lots of WSASends outstanding to lots of clients is that the send operations may be taking longer to complete and so make it more likely that your bug will be hit...
It doesn't matter how many WSASends you issue as long as your clients are able to receive the data as fast as you can send it. As soon as you are sending faster than they can receive then there will be problems. I address these problems in this answer.
i thought it'd be better to rephrase. my earlier formulation of my question could have been better focused. the trouble with presence notifications, while real and still recurring, is kind of minor. the things i haven't figured out yet i can fake or work around. much less of a concern than getting basic text chat messages moving between users.
again, still fairly new with this combo of tech flavors - using libjingle as the heart (and liver and kidneys...) of an iphone xmpp/jabber app. got the sign on part, the presence notification/roster updating business actually seems to be working more or less as it should. but xmpp text chat message stanzas seem to vanish before making it out on the wire. capturing other network traffic, and perusing the pretty packets, i yeah, i can see the exchanges for sign on, etc. that got us going, but then nothing for chat.
i've checked and double checked how i'm putting together the stanzas, attributes, namespaces, etc. everything looks jim-dandy to me. i can see that a message is getting queued in the libjingle internal infrastructure. but no results on the ethernet.
hoping somebody who has played around with this stuff before might remember a similar stumbling block and can offer up a hint, suggestion, or pointer in the right direction.
thanks for any help.
mike
I am writing a program that composes an email reply. The original email may be a reply already. How should I handle the subject?
I have seen the everything-before-the-colon method used. This could affect a situation re[2]:. If the colon method was used. The reply would become Re: and the other party's computer would lose count.
If not, the reply would become Re: re[2] Then the next reply could come through as re[4] as was intended.
But the colon method can be useful for cases where you say Resending: and the next reply would become Re:.
Do you have input on this? Is there a standard or common way to do this?
(With no context at all it's difficult to provide a concrete answer - you may want to provide more information in your question)
Most decent mail user agents (MUA) use the In-Reply-To: header to indicate message threading, without resorting to unsafe operations such as parsing the Subject: header. Most such clients also have a proper threading mode where unusual stuff such as Re[2]: is at best unnecessary. The de facto standard of using Re: is a good compromise between terseness and content, but with proper threading support it eventually comes down to aesthetics.
Just use Re: in messages you create yourself - anything else is bound to lead to confusion. Make sure you properly generate the In-Reply-To: header for any reply messages.
Please do not remove content from the Subject: header. You may refrain from adding to it when e.g. a proper Re: substring already exists, but if you are actually removing strings you are bound to get it wrong, leading to confusing situations.
This is not a strictly technical issue - different people have different preferences. In a specific community, e.g. a mailing list, social automation (sic) will take care of any repeat offender that uses strange or confusing conventions.
Trying to deal with this automatically is bound to cause more problems than it would solve. Such issues are also not the responsibility of the carrier - i.e. the mailing system. Keep your system simple and focus on real technical problems.
EDIT:
A common case of a broken client (or user - I have always been unclear on this) is the Re: avalanche case:
Subject: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: What about that thing we were talking about?
Tempting isn't it? A simple filter rule in the MTA, or a few lines of code in a replying MUA and the avalanche is replaced by a nice, single Re: automatically!
In my opinion, this is one case where the temptation should be resisted to:
There is no guarantee that an MTA is the only path a specific message uses. For example, when some users reply to mailing list messages, they reply both to the mailing list and directly to the poster. Naturally, the poster will receive both messages, most probably by completely different paths.
Do you know how confusing it can be to receive the same message with two different subject lines? Even a basic sort-by-subject would fail. In my opinion, even spam detection systems that add [SPAM], **SPAM**, $P#M or whatever to the subject are pushing it.
Can you imagine a library selectively changing the titles of their book copies according to some sort of local policy?
Even if your MUA "fixes" the issue, everyone else will still be using the old subject, except for when replying to you. Moreover, you have just single-sidedly created what appears to be a new thread. Proper mail clients will still display the thread correctly, but the visual effect is confusing. After all, you did remove a highly distinctive feature of this thread from your reply post, didn't you?
I actually remember a couple of fun threads where the Re: avalanche in their subject was part of a tongue-in-cheek discussion. Why would you want to miss on that?
Sure, people use broken clients. Or they are broken themselves. If anyone gets really out of line it can be handled individually. Just don't compound the problem and leave our Subject: headers alone. Please? Pretty please?
I was working on something for a client today when I found a way to break some functionality in our program.
(The code is really legacy code, it's been in development for about 10 years and I've only been working here for about a year.)
It didn't cause an error, or cause the program to crash, but if a user was using the program and duplicated the behavior I'm pretty sure they'd be holding up their "WTF?" flag.
In our program we have named fields (textboxes) and static text (labels) that can be linked with the textboxes. When the textbox is not filled in the label(s) that were linked to them disappear.
The functionality that I broke was, when you change the name of a textbox that already has one label or more linked to it, and save the file, without re-associating the one or more labels associated with the textbox, the formerly-associated labels appear when the textbox is blank.
Now my thinking on the matter is that a simple observer pattern could have solved this problem in the first place, but then I didn't write the code.
I was thinking that if I could dig up more situations like this with the guys in my shop, that maybe I could talk them into considering unit testing, decoupling, applying patterns where they are called for and the like.
So for this reason I was wondering if anyone had any tips for finding broken (but not error causing) functionality in any sort of app (web-based, desktop, etc...)
For an app to fail usability, it has to have a defined set of expected behaviors.
"Is this textbox SUPPOSED to do nothing when the enter key is pressed?" Maybe it is, maybe it isn't. I've seen apps where a tester/reviewer reports something that they ASSUME should work another way, when in actuality the client specifically asked that they DON'T want the form submitted on a return key press, but only a submit button click.
So basically you have to define proper behaviour before you can determine incorrect behavior.
Hire some testers.
If it has an interface, then one of my favorite unconventional test is putting 5-10 year old children in front of it. You'd be surprised what they can come up with (especially the younger ones). While this may sound like a joke, it isn't -- it really works, because children don't have the mindset of only going through "mindset" paths.
And yeah, children are the experts in "breaking things" xP.
Code inspections, i.e. reading the source code: if you had taken time to read/inspect the source code, looking for "smells" or even just looking for code whose behaviour you don't immediately understand and agree with, you might have been holding up your "WTF?" flag too.
Test, test, test.
Do unexpected things. Start doing one task and switch another to see if anything goes haywire. Use the back button when you're not supposed to. Open it in two windows. Let it time out.
Test in all browsers, especially IE.
You can find database connections/sessions aren't released by:
working out the minimum number of connections you need to do something
setting resource limits to that minimum number
ensuring one "run" of the scenario that should use exactly that number (and release it afterwards)
then run it again a few times... do you run out of connections?
I used to work in a company where programmers regularly used to forget to de-allocate db connections. The standard answer was to reduce the resource to a minimum to see if there's a leak - and to try to work out where it is by restarting the system and running different scenarios repeatedly.
The first hour of code review, with the first reviewer, will do the most to find quality problems. But here's the thing: You don't need to convince people of quality problems. You need to convince them of the value of fixing bugs, and of rewriting only when the present quality absolutely justifies it.
I've dealt with some seriously bad code in my time. But you can't just rewrite. You need a spec before you can even tell if the rewrite is an improvement.
Sometimes, you have to infer the spec from the code and then check it against some human somewhere. But by the time you've done that, you understand the code as written and are now better prepared to repair than to rewrite -- most of the time.
Repair proceeds by a process of small behavior-preserving modifications that render the spec more clear in the code. Then, when you find something that looks wrong, you don't just change it. You ask around until you find the person responsible for that decision, and you get them to show you where in the spec it says that behavior X is correct. (This conversation can take many forms.) If you're lucky, they'll tell you that behavior X is in fact incorrect, and then you've earned your pay.
assert()
Also unit testing with coverage analysis.
This is particular to the Visual Studio IDE, although it probably also applies to others:
During testing, always at some point run in the debugger with "Break when an exception is thrown" turned on.
This can often help expose exceptions which are incorrectly being silently caught and which represent bugs, but otherwise may not be evident.
Code reviews should always also include reviews of the unit test code.
The problem is that with ad-hoc testing it's impossible to know how much or how well a developer has tested their code. So, you're at the mercy of different developers definition of the word "done".
If you include reviews of the unit test code at the same time you review the production code you should have a good idea of whether the code is really complete; in that "complete" includes "tested". Not just "Hey, I'll throw it over the wall to the testers!".
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Re the recent question at when are modal dialogs truly necessary?. WHY are modal dialog boxes evil? Is it because people don't read them anyway? Because they are often implemented so poorly? Something else?
About half of the answers so far are addressing the flaws of confirmation dialogs, not of modal dialogs. While the vast majority of confirmation dialogs are modal, this does not mean that the two terms are synonymous.
A modal dialog is one which puts the program into a specific mode and does not allow you to do anything which doesn't correspond to that mode while it is open. In the most common implementation, this means you can't access any other windows.
This is evil.
Consider an address book application. Suppose you have an existing person in the address book and you wish to add their roommate.
If the "add person" dialog is non-modal, you can flip back and forth between the old record and the new one copying and pasting your data.
If the "add person" dialog is modal, you can't do anything with the old record while the add dialog is open. You can select something to copy before selecting "add", but just one thing. Everything else has to be manually retyped.
On rare occasions, you run into something which truly must be done in one piece without allowing the user to diverge from that task until it is complete. Modal dialogs are appropriate for such cases. But these cases are very rare! Which is basically the point of the other thread referenced by this question.
People don't read them, and that's a good thing. You want people to form habits around your UI, but having an important choice in popup is just going to make the user hit OK.
They interrupt the user, they prevent the user from doing other things.
What if you wanted to copy and paste something off the main window? What if you wanted to copy the message in the modal dialog? What if you don't care.
Just compare IE's Find dialog vs Firefox
Compare IE's "Do you want us to remember this password for you?" to Firefox
The best UIs are modal. As are the worst.
A modal UI - regardless of whether it is built from dialog boxes, toolbar buttons, or text prompts - is only desirable so long as each mode matches the expectations of the user transitioning to it. When the program transitions into a mode unexpectedly... or the mode requires the user to possess information he does not have readily available... then it will cause the user hardship, either forcing him to revert to a previous mode or guess at the proper action with potentially undesirable results.
A non-modal UI is a complete set of tools. Some are relevant to the job at hand, some are not. A user must have sufficient skill both to choose the correct tools, and to apply them in the correct manner. While a non-modal UI can therefore never be as optimal as a good modal UI (the right tool for the current task already in hand), it can also never be as sub-optimal as a bad modal UI (the wrong tool for the current task slamming into your careless fingers).
Designing a good modal UI can be a fiendishly difficult task for non-trivial applications, especially for general-purpose programs intended to be used by a wide variety of users for an even broader range of purposes. Menu systems and dialog boxes attempt to bridge the gap, allowing small, task-specific modal sections in a larger, non-modal application. Neither one scales particularly well however, and mis-use and overuse have left them with a bad reputation, often seen as the first refuge of the lazy programmer. Dialog boxes in particular are often used more as a means of forcing users into a programmer's (or designer's) idea of how an application should be used, or punting difficult design decisions and tricky error handling at the user, rather than for their namesake goal of communication.
Indeed, the rise of web applications has brought such tendencies to the surface in numerous forums, newsgroups, and Q&A sites such as this one, as programmers accustomed to writing ultra-linear logic which prompts users for input when needed by the program rather than when available to the user... are forced into a system where users can navigate non-linearly, and may well view any attempt to restrict this freedom as a quaint annoyance to be subverted rather than a necessary evil. The plaintive wails of these poor coders echo around the 'Net as their attempts to force this crude modal behavior onto a non-modal system come crashing down around them. For those of us who have long suffered under their cruel "dialogs", it is a lovely tune indeed.
Before you get to read my answer, you must carefully read the following message in it's entirety. All processes, subprocesses, tasks, and threads are suspended indefinitely pending your answer. And, once you completely understand the message, and possibly agree to some legal stuff, and all the implications of all of this, then and only then can you proceed.
In a consumer style application, they are more or less useless; users don't read them, learn to dismiss them, and when they DO read them, usually end up being confused. I think a Yes/No/Cancel dialog is downright lazy UI design. The "buttons say what they do" dialog is slightly better, because the user doesn't have to read much.
That being said: In data-critical intranet/"enterprise" applications, they are more or less necessary to confirm destructive actions or to sanity check non-standard workflows that may be allowed but not recommended.
So, I don't think they are conceptually "evil", but more often than not, the result of bad UI design.
They are evil because they violate the basic principle that the user is supposed to be able to direct the software's action. Modal dialogs (the evil form of dialog boxes in general) constrain the user to only one action.
Some answers seem to misapprehend that it's any popup that asks for e.g. user confirmation. This could be accomplished without tieing up the entire app or computer; it's this behavior that people object to.
In some environments, modal dialogs only constrain the user in the context of a single application (or maybe less). Really bad modal dialogs prevent the user from doing anything else in the entire operating system (say, Windows).
One of the reasons that I don't like them is because they are showing information in serial(one lot of information at a time) and not parallel(all the information you need to see at once), parallel will allow the user to choose what they want to look at where as in serial you are pretty much forcing them to pick an option.
Plus also the fact that they break a users flow of control(eg steals focus from the object you working on) which I really don't like doing. So in effect from this the user will just hit OK so that they can get back to what they where doing and ignore the information in the dialog box.
Mind you you still need them in some cases.
I don't remember where I saw this first, but a better approach to a modal dialog is often to allow an easy to find and use "undo" capability. Windows Explorer actually does both when you delete a file. It asks for confirmation (modal dialog), then, immediately after deleting the file, the Edit menu has an "Undo Delete" option. just a simple way to access the Recycle Bin, for sure, but in this case, Microsoft really could have just done away with the dialog.
The point being, you can often do without the dialog with a bit of thinking, and perhaps a bit of extra code, but it's just too easy an option for a lazy, or perhaps, more generously, a time-constrained developer.
That said, sometimes you really want a dialog. Think about all of the options on a typical Print dialog. Which printer? All pages, or just a few? How many copies? I don't know how you'd do that without a dialog box...
Noboy reads them, and they interrupt the program flow. Often when used as error notification they are the precurrsor to a program failure. By the time the user realizes what is going on, the message is gone and they are left to recall or invent the message as best they can.
Personally I think it depends entirely on how it is done.
Try copying 10 files where every file exists in the target directory, do it using Windows Explorer.
Is a single modal dialog for each file really the correct answer in such an operation. I know you have "Yes to all", but the entire loop system should've been built differently. It should've gathered all the files that exists into one big list and asked once "What do you want to do with these files", and then let me decide for each file down the list what to do before clicking OK and resuming the operation.
And lots of times dialog boxes just interrupt the normal workflow.
And yes, people don't read dialog boxes. So a golden tip if you must use a dialog box is to reword it.
Instead of "Do you want to delete this row in the database?", try wording it so that you're asking (but this isn't worded right) "Do you want to not delete this row in the database?" This way, if they just hit Yes, which is the typical response from a user who just wants to get on with it, they'll end up doing nothing.