Thursday, June 21, 2018

web app - Does "Don't Break The Back Button" Apply To Web Applications?


I've read the advice, "don't break the back button" from multiple sources. For content-based browsing I agree with this 100%. Does the same advice apply to web applications? I feel that it is still valid for web-app pages that simply display data. Once posting forms, AJAX, and logged out sessions become involved, the back button might result in unexpected behavior.


Is this advice relevant for a highly-interactive web application?


Here are some articles that speak to this topic:
http://w3.org/QA/Tips/reback
http://brightorangethread.com/blog/view/dont-break-the-back-button

http://nngroup.com/articles/the-top-ten-web-design-mistakes-of-1999




fiction - Getting Inside Someone Else's Head


A common problem for novice fiction writers, and one that I feel that I myself haven't quite graduated from, is always writing characters who are like the author. Each character is merely some facet of the author, at worst a caricature and at best a well-rounded reflection of the author.


I read a quote at some point that I can no longer find to the effect that the best authors can actually write people who are other than themselves. These people get inside the heads of their bosses, co-workers, siblings, parents, friends, spouses, lovers, etc. and pluck out real reasoning, real fears, real desires, real loves, and real hatreds to make realistic characters who are alien to themselves.


How would I go about doing this? I understand that it takes empathy and an active interest in other people, but once I have insight into friends, how do I go about writing it? Is there a writing exercise I could use? Is it even a valuable pursuit?



Answer



One thing you've got to remember as a writer is that you are not, in any spiritual sense, getting "inside people's heads". What you are doing is producing an artefact that convinces other people that you are inside the minds of many different characters but only as long as they don't look too terribly hard. Your question poses a worry that you can see that all your characters are just variations on you, or that you are having some difficulty drawing the line between where you end and your characters begin.



Much apart from anything else, this is a problem of things not being realistic enough. After all, there is only one you and all the people who aren't you are someone else. Therefore any exercise in writing that does not feature you as a character must feature loads of people who are not at all like you and none that are. If you produce a work which has many variations on you and no one that is not you that's a problem, right?


Well, no, not as such. You don't have a choice about lending some aspect of you to every character you write - after all, you're writing them. As I said when we looked at this problem at first glance the problem is not actually writing characters who are not you. It is making other people happy that all the characters are not you and most importantly letting you know all your characters are not you.


The closest experimental parallel I can think of is with the experience of the actor. I was interested in acting for many years and, when taking on a part, I used to try my best to get under the skin of the character. Contrast this mental experience with the advice of most acting theorists; the most famous, Stanislavski, talks in no uncertain terms about the difference between acting something and being it.


To Stanislavski, experience of reality is a completely separate thing from acting out that experience for an audience. He talks about the essential property of emotional distance from the character you are acting. The character may be overwrought, therefore the actor must act out overwrought but the actor must not be overwrought because that is just self-indulgence. The actor's duty is to communicate the experience to the audience so they can be moved by it, the actor must try not to be.


Stanislavski's point of view has been argued about but I think there is much of merit in it. I knew many young actors (at one point I was among them) who spent enormous amounts of time psychoanalysing the character who subsequently turned in a performance that a 2'x4' would have been proud of.


Another of Stanislavski's lessons which is pertinent here is called the "magic if". Essentially the characters in plays have families which are not like the actor's, they experience circumstances and have histories which are not like the actor's. In order to "get into character" Stanislavski positively encourages actors to ask how it is they would feel in the exact same circumstances, so "what if my uncle had murdered my father and married my mother, how would I tackle this situation?".


The purpose of this exercise is to measure ways in which you, as a person, are similar to the character you are playing and how you are not the same at all. Essentially your sense of difference from the character as an actor helps you know how to portray them without getting confused and being them. The actor who identifies too closely with his role is a subject of dark, horrific melodrama for good reason. It's not pleasant to feel too close to your subject matter.


So as a writer where does this leave us?



  1. Don't panic about your characters sharing aspects of you, this is inevitable.


  2. Your writing, like an actor's acting, performs the job of representing a world of rich and distinct personality, not actually being one.

  3. The problem here seems to be of gaining some distance and perspective from the characters you create.


3 is the troublesome one. I would suggest two things:



  • Write a story in which you are a character. Nothing acts a distancing mechanism better than consciously trying to do something you're afraid you're doing by accident. (HINT: I expect you'll find it hideously difficult.)

  • Write about a few characters who do things that you most certainly wouldn't do and work out what motives they could have had for doing them. Comb through their motivations because characters are made from such things.


Hopefully these two exercises should start giving you the distance that you need.


creative writing - How to write Arabic in dialogue for an English piece?


I have a character who is a Syrian refugee to Canada. His first language is Arabic, but he's lived in Canada long enough that he's learned English and uses this as his primary spoken language. On occasion he'll use Arabic words in his speech, such as when he's not sure what the English translation is, but I'm unsure how this should be written in text for an English audience.


My thought would be to use the phonetic spelling, for example:



"Alaistirkha'" Essam breathed tossing the book onto a nearby table, "It is not my place to say."



Or should it be:




"الاسترخاء" Essam breathed tossing the book onto a nearby table, "It is not my place to say."



What is the correct way to write this?



Answer



As you are mainly writing in English your target audience is probably from English speaking countries without a lot of knowledge about Arabic. It's not a common language to learn when compared to something like French or Spanish as far as I am aware of. As such you should be careful about using a language other than English in your text. I am from Germany for example and have never learned to speak Arabic. I would have absolutely no idea how to pronounce the second version, which is a problem for me when I am reading something because it completely breaks immersion. I would need to think about what the character in my head would say and how it would sound. And that's not possible when I can't read the word.


With the phonetic spelling I have a pretty good idea of how the character would say it. It's probably still quite far off, because I can't understand Arabic and wouldn't know a native Arabic speaker would actually pronounce it, but I would have an idea. And that's what I need to stay immersed in the story.


Especially when you are doing this more than just once or twice I would be careful. The second version is factually more correct than the first one, but for people who can't speak and read Arabic it's impossible to have a feeling for how your character sounds, which many people don't like.


You could also try to get around this whole issue by describing what he really wants to say with an addition that he is saying it in a different language than you are using for the reader's convenience. Something like:



'Relax' Essam said to himself in Arabic, taking a deep breath and tossing the book onto a nearby table.




It's easy to do and won't lead to any kind of confusion. Because the first version you propose could lead to a bit of confusion with people who speak Arabic and might wonder what word you mean exactly with the phonetic spelling as it's written completely different from the "real thing". And your second version will lead to confusion with people who don't speak Arabic, because they won't have a clue about how to pronounce that and whether they got the meaning right from the context.


There is no "correct" way. Only different ways with different levels of clarity for different target audiences. For the general English speaking public you just want to be careful with incorporating different languages into your text.


website design - How to handle lots of legal text (40k words) on a webpage (also mobile)


I want to redesign the guideline (rulebook) page of my sport association. The problem is that its a legal document which contains a lot of text (around 41.000 words) with a lot of (sub)headlines and chapters, currently just plain html. Not very neat.


Its based on a PDF and because its a legal document I cannot rearrange the chapters or separate it.


Im now looking for a solution to make it a little bit more usable / readable. I understand that I will not get an AWESOME user experience with so much text...


Does anyone of you have tips how to handle a lot of text on a page or can show me examples where its handles very well?


First approach:


Today I noticed a bootstrap site does this really nice on this page: http://getbootstrap.com/getting-started/


I like their sidebar solution, the problem is just, when switching to a mobile screen resolution, the design just adds the sidebar to the bottom, which makes its completely useless.




Answer



I would consider creating a set of FAQ questions that link to the specific legal section. This will make the mass of legal information accessible, as the FAQ can use common language to describe a situation and act as a 'translator' for locating the legal jargon equivalent.


You may need create a semantic link between the common language and specific legal jargon - eg. 'What if a ball is passed backwards?' -> 'See section 3.2.5 Traversing of ball in opposing direction of play' Where the link is the section heading.


Technical Considerations



  • Split the doc by at least top level sections into separate html pages. For mobile this will decrease the download and formatting time required to show the page

  • Consider the frequency of updates. If this is something that can be set and forget then a manual method of formatting can work. You may consider a model to produce both the PDF and web pages from a single source if updating is frequent


One trend of late has been to try and iconify or otherwise provide a brief, simply phrased version of a vast legal tomb. Again it is in the interest of engagement and providing a lower barrier to entry. Have a look at: http://tosdr.org/ and https://about.pinterest.com/en/terms-service as examples.


Wednesday, June 20, 2018

interaction design - Guidelines for autocomplete widgets


What guidelines exist when working with autocomplete widgets? I'm hoping for general guidelines that apply across different application types: web, desktop, and mobile.


A response to a Search as you type thread included the following relevant items:




  • Never update the search input with one of the results unless the user requests it.

  • Provide keyboard and mouse access for selecting results.

  • Look-behind is a nice complement to look-ahead.


I've observed a few other practices:



  • Highlighting the searched-for term

  • Returning the count of matching items

  • Providing an action indicator upon selection (but not activation) of an autocomplete entry

  • Offering the originally typed text in the autocompletion list



In addition, the following questions may be asked when providing suggestions:



  • How many hints/suggestions should be provided?

  • How do you resolve those that should be displayed when many are available?

  • Should suggestions take into account likely spelling or typing errors?


Any responses discussing more complicated syntaxes like boolean expressions would also be helpful.



Answer



There are no general guidelines that work across all platforms and all applications, take for example Google web search and selecting a person from a list of coworkers - in both cases an auto-complete widget may be appropriate but every detail of the implementation will be different.



The only thing you can do is evaluate the specific needs of every application (not platform, who cares if the form you are filling is in a web browser or a dialog box) and have usability test to see what features you need (users misspell options often -> you need to take spelling error into account).


Let me quote from an old interview with Tim Lister (one of the authors of Peopleware):



Cramblitt: What do you think about the reliance on best practices?


Lister: I get chills when I hear that phrase. From my point of view there are some pretty good practices, but no best practices because that implies generic software development. All projects are related to the domain they’re in. A best practice for defibrillator software is not the best practice in another domain. I’d like people to think about patterns – abstracting their work and recognizing the patterns they’re in, good and bad, and making informed decisions to promote those patterns or replace them.



tables - When to save data?


When should I save data in an business application?


We have a lot of applications and currently they have not all the same behavior. I am not very experienced with UX and would like to know when I should use AutoSave behavior and when a Save-Button.


The main applications have all a tree-structure on the left hand side and on the right hand side you can edit some data for the selected item in the tree. The data is separated and displayed on different tabs.


The behaviors we have:




  1. Tree is saved automatically; data saved on tab-changed or application closed and selected item of tree changed

  2. Tree is not saved, only when save-button is clicked. No tabs on right side.

  3. Tree is saved automatically; data is saved automatically, except there is some invalid data.


The data is often displayed in DataGrids (WPF).



Answer



You pretty much want to go for one or the other extreme, where the extremes are:




  • Explicit Save for Everything. Everything needs saving through an explicit command.





  • Autosave Everything. Everything is saved automatically and instantly.




You want the user to have as simple a mental model of the system’s behavior as possible. You don’t want to burden the user with trying to




  • Predict when they need to explicitly save and when they don’t .





  • Understand that the system won’t let them perform certain actions because they haven’t explicitly saved some edits.




  • Figure out what action triggers an autosave (e.g., changing a tab).




  • Deal with the need to close a window or pane to commit their changes (in many situations, users prefer to keep a few key windows constantly open so they can easily return to them periodically as their work dictates).





To achieve this, Explicit Save for Everything should work like this:




  • No edits in the window –neither the tree nor the tabs –are saved until the user explicitly selects a Save command.




  • A single Save control saves all changes in the window, both for the tree and the tabs.




  • The users can make an arbitrary number of changes to everything in the window before selecting Save. A user can change the tree, multiple fields in multiple tabs, and multiple database records in the window, and then a single click of Save saves all changes. The system never forces the user to choose to Save or not before doing something else, except when the user tries to close the window with unsaved changes.





Autosave Everything should work like this:




  • Everything in the window is autosaved, both changes in the tree and changes to the tab.




  • An exception can be made for input to dialog boxes, but these should appear as separate small windows (or lightboxes, if you insist) with the familiar OK and Cancel buttons. As always, dialog boxes should be limited to just a few fields –something the user can complete in 20-30 seconds.





  • Autosaves are performed immediately for each meaningful atomic user input. If the user clicks a radio button, that change is immediately saved. Edits to small text boxes are immediately saved when the text box loses focus or the user hits enter. While the user is editing the text box, it should preferably assume a “tentative” graphic appearance (you need to test what this may be).




  • Ideally autosave should be combined with auto-refresh, where objects a user is viewing are automatically and promptly updated with changes made by other users. The idea is to get the users away from this complicated mental model of them working on a copy of objects, and get them thinking they are working directly on the real objects -that the UI is a like a physical control panel.




  • Undo is necessary for any app, but it’s especially important to have sophisticated multi-level undo when you have autosave.





The choice between Explicit Save for Everything and Autosave Everything depends primarily on the performance capability of your system. Generally if your bandwidth can handle Autosave Everything, do it. The requirement to save remains a user error waiting to happen. It also adds work to the user. It’s about time autosave became standard for all apps.


However, precisely because requiring save is an error waiting to happen, just about every user has lost a tragic amount of work due to not saving, turning nearly all of them into compulsive savers. Autosave can thus make users anxious, and you may not want to use it unless you can through training and documentation repeatedly assure users that their work is automatically saved.


business - Advice on re-quoting a client for a freelance project


I took on a graphic design job recently and I quoted the client for 36 hours of work. About half way through the project the client got stalled out because of upper management's indecision and because of that, many little changes started being made to the project. I am now up to almost 80 hours on the project and foresee another 10 before it's finished.


This is my first job with the client and I would like to continue receiving projects from them and hopefully procure a long-term relationship with them.



Should I consider this an investment and just charge them for the quoted work? Or should I re-quote them and if so, how should I go about doing that? Should I re-quote them the full amount?


What is the general practice for a situation like this?


Thanks!



Answer



This time: Pekka's answer is good.


Next time: Pay attention to how many hours you're putting in. As you approach the estimate mark, you send a note to the client, saying "Hey, I quoted you for 36 hours, which was to cover services X, Y, Z, A, and B. We're only done X and part of Y, and I'm up to 30 hours already. I'm happy to continue working with you through the completion of the project, but I don't want to sock you with a surprise bill. I can work up a new quote for you based on the progress we've made so far, or I can just bill you at $X hourly rate. How would you like to proceed?"


This shows the client:



  • you're paying attention to the client's bottom line as well as your own

  • you're willing to be flexible about payment BUT you're also not going to let yourself get railroaded


  • you're considerate enough to give them wiggle room before the monetary deadline, so they have room to renegotiate on their own side


If the client asks "how did we end up with so many hours?" then you give them the breakdown as Pekka outlined.


In this case, it's easier to get permission than forgiveness.


technique - How credible is wikipedia?

I understand that this question relates more to wikipedia than it does writing but... If I was going to use wikipedia for a source for a res...