January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] printString and asString

by Esteban A. Maringolo

In my experience with Pharo and other Smalltalks as well: #printString is used for debugging, that's why the default implementation shows the class name. It's implemented using #printOn: #displayString (deprecated in Pharo*) is used to display the object in the UI. It is implemented by means of #displayOn: (Dolphin used this pattern) #asString is the toString() equivalent of other languages. In some cases `anObject asString asObject` should give the same object back (e.g. in Date, Numbers, etc.). Most of the times it is the same string as #printString, but it is not consistent. Ej: If you have aPerson: aPerson printString -> "aPerson ('John Doe')" aPerson displayString -> 'John Doe' Regards, (*) Why #displayString was deprecated? Esteban A. Maringolo 2014/1/3 Frank Shearar <frank.shearar(a)gmail.com>: > On 3 January 2014 11:44, Otto Behrens <otto(a)finworks.biz> wrote: >>> 'Conversion' implies using the resulting String in some further >>> computation. 'Printing' usually implies displaying something to the >>> user (and nothing more), or serialising to a file/network. >> >> What kinds of computation are you thinking of regarding a string? I >> think I understand what you're saying, I'm just trying to make it a >> bit more concrete in my mind. > > I just mean that sometimes you want to work with a string > representation of a thing, and #asString is how you get it. For > instance, a Symbol might printString as '#foo' while in its converted > form it returns 'foo'. > >> The requirements of displaying something to the user and serialising >> to a file/network are quite different, or not? > > You're right. I'm wrong in saying that #printString should be used to > serialise anything. Actually, you'd probably use #storeString for > serialising, if you weren't using Fuel. > > frank >

Jan. 3, 2014

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Sebastian Sastre

I felt we didn't disagree but wanted open that line of conversation because it sounds heathy :D I agree the tests for our tool aren't going to be the same as for many web sites/apps. One thing is to try to create a great experience for woman buying shoes in the web and another is computer science students/enthusiasts hacking something useful in a few hours. After all, smalltalk is all about bringing usability to software-making. All about the creative spirit easily telling machines how to behave In our ideal, easily = creative flow On Jan 3, 2014, at 10:07 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Sebastian, > > I think you read my mail too literally :). > > We do not disagree. My comment about "Don't make me think" is that what applies for the web is not quite the same as for a programming environment. For example, on the web, it is more profitable to assume that everyone is a newcomer, while in a tool where you spend a lot of time this is not necessarily the case. > > That said, of course, doing usability experiments is indeed useful (and hard to grasp :)). I did not argue against that. It would be great to start any effort in this direction. > > Cheers, > Doru > > > > > On Fri, Jan 3, 2014 at 12:49 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Our engineering bias make us think too literally some times. > > Let's stay scientific but use the designer hat instead of the mathematician hat. > > I know is for the web, but don't you have the feeling that you can design an experiment in a way that will converge to the same usability principles? > > There are things in Krug's way to document the experiment that could have the same degree of validity even for hardware devices! > > Don't make me think, as usability principle, is the most generous thing you can do for the user. When you do that, what you are also doing is saving the user's neocortex energy to solve other problems (their social, environmental or personal problems). Is how you help them to change their worlds. That's the closest thing to your mission accomplished. > > Cheap idea for us: > > 1. Design a simple experiment. And yes, simple for them is not the same as simple for you! > 2. One morning per month (maybe that's too much, one every 3 months would be a huge leap forward) > 3. Take 3 or 4 computer science students unfamiliar to Pharo, I'll say that's the adequate audience > 4. Bribe them to participate with a cappuccino with croissants or something > 5. During the experiment, ask them what are you thinking now every time their flow is interrupted > 6. Discover their assumptions. Don't explain. Listen! (and document). Take notes like crazy* > 7. Don't panic by overwhelming issues. Discuss with colleagues or publish in a private wiki for the team or something > 8. Decide what are the 3 most blocking entry barriers and show that to the team. We need to discuss the discovered issues do, together, something about them > > > *Your mission here is not educate the guys, only to document which are their assumptions. You might feel frustrated by the state of education today or the poor preparation they had or the bad influence of industry vices or how anxious and distracted young people are these days. Nothing about that should change your mission of discovering their assumptions, so the best is to ask them, listen, document and share with maintainers. > > > > > On Jan 3, 2014, at 7:48 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Thanks for bringing this up. >> >> Yes, we should care about usability. >> >> And I agree that usability is attainable as long as you approach it with consistent discipline. It's similar to designing code: you start asking questions, figure out what the right questions are, and then stick to it. >> >> I like Steve Krug's Don't make me think book. However, please keep in mind that the lessons in the book apply specifically to the web. An environment like Pharo should not obey exactly the same things. >> >> But, as Esteban says, let's focus on the future, and keep usability high in our list of concerns. Even if we might not know how to do it now, simply sticking with it will make us better in the long run. >> >> Cheers, >> Doru >> >> >> >> >> On Fri, Jan 3, 2014 at 10:38 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi Sebastian, >> >> I feel your pain :) >> >> we are aiming to focus Pharo 4 in âmodularisation and toolsâ, to enhance what we have currently. >> Nowâ¦ one of the biggest problems we have is that people is so used to the old tools that they donât even realise that we can do a lot better. And most possible some people will react violently to any changeâ¦ but well, we will do it anyway, with your help. >> Letâs all together build a better IDE for the future :) >> >> Esteban >> >> On 03 Jan 2014, at 01:13, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>> Guys is no mystery that we have some issues with UI. >>> >>> It's not so bad either, we have many things that are light years ahead of other but we consistently miss some really basic stuff from the Human-Computer-Interactcion point of view. >>> >>> The community is biased towards engineering and unbalanced regarding to design so this is no surprise (why this happens is another interesting conversation). >>> >>> UI is not that hard when you know what to pay attention to but we need first to decide if we care about usability and the developer experience at all. >>> >>> This fantastic talk from Steve Krug exposes what's the least you can do for the usability of any software. >>> >>> http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-abou… >>> >>> sebastian >>> >>> o/ >>> >>> >>> >>> >>> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 3, 2014

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Stephan Eggermont

Sebastian wrote >Cheap idea for us: Good idea for a bit later, and for the new parts. We already have a number of well-known problems for new users. If we donât eliminate them first, weâre not going to find much new issues. They will be hidden behind: - no discoverable way of creating classes & methods; - buttons in the system browser without a visible relationship to the pane they operate on; - context menus that donât operate on the selected item but on a whole group; - menu size - modal editing - keyboard navigation of the ui There are quite some Pharoâers teaching introductions to smalltalk. I think they are aware of these issues. A few of them are on my slides, at least. And a few I always have to explain. Stephan

Jan. 3, 2014

guiding code changes with gtinspector

by Tudor Girba

Hi, I think the inspector should become more prominent in the life of a Pharo developer. For example, the Inspector is perhaps the last tool you might see as useful for code manipulation, but if you see code as objects, it makes perfect sense to have some support in the inspector. To show how it can be different, I described two recent scenarios in which the GTInspector was essentially the only tool readily available to support editing of a custom set of methods: http://www.humane-assessment.com/blog/guiding-custom-changes-with-gtinspect… I would be happy to hear any feedback. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Esteban Lorenzano

On 03 Jan 2014, at 12:56, J.F. Rick <self(a)je77.com> wrote: > As somebody coming from the HCI side, rather than the software engineering / programming language side, I too value usability. But, it seems to me that you first do the major changes and then slowly hone to get usability right. I find lots of small little usability bugs in Pharo 3.0 but I assume that those are mainly due to the tools getting majorly upgraded right now. I'm not sure how to report these tiny usability bugs. If someone can chime in on the correct way to report these, I'd be willing to report them. For instance, I notice that when I am writing code in the browser and click to another method, I am no longer warned that my code will be lost. It is simply lost. That's a basic usability thing: Prevent costly errors. But, I assume that this is just a matter of Nautilus still getting refined. So, it may not even be worth mentioning. Please, report them in the tracker, under âUsabilityâ project (I just created it :P ). nowâ¦ in the case of the lost changes in Nautilus: it was a bug. Bahâ¦ it was an attempt to enhance the edition that didnât work (for now). So it is reverted, latest versions should not have that problem. > > My main contribution right now is being an early adopter of Athens and sending any weaknesses I find to the list. Athens is new and still has lots of little bugs. At the same time, it is ambitious and a major step forward for Pharo if it can be fully integrated. Of course, these little bugs will get taken care of as Athens is more widely used but part of the excitement of Pharo is that it is evolving. There are some areas where usability honing can be useful but others were the software engineering has to settle down before the honing can start. > > Cheers, > > Jeff > > > On Fri, Jan 3, 2014 at 10:48 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks for bringing this up. > > Yes, we should care about usability. > > And I agree that usability is attainable as long as you approach it with consistent discipline. It's similar to designing code: you start asking questions, figure out what the right questions are, and then stick to it. > > I like Steve Krug's Don't make me think book. However, please keep in mind that the lessons in the book apply specifically to the web. An environment like Pharo should not obey exactly the same things. > > But, as Esteban says, let's focus on the future, and keep usability high in our list of concerns. Even if we might not know how to do it now, simply sticking with it will make us better in the long run. > > Cheers, > Doru > > > > > On Fri, Jan 3, 2014 at 10:38 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Sebastian, > > I feel your pain :) > > we are aiming to focus Pharo 4 in âmodularisation and toolsâ, to enhance what we have currently. > Nowâ¦ one of the biggest problems we have is that people is so used to the old tools that they donât even realise that we can do a lot better. And most possible some people will react violently to any changeâ¦ but well, we will do it anyway, with your help. > Letâs all together build a better IDE for the future :) > > Esteban > > On 03 Jan 2014, at 01:13, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Guys is no mystery that we have some issues with UI. >> >> It's not so bad either, we have many things that are light years ahead of other but we consistently miss some really basic stuff from the Human-Computer-Interactcion point of view. >> >> The community is biased towards engineering and unbalanced regarding to design so this is no surprise (why this happens is another interesting conversation). >> >> UI is not that hard when you know what to pay attention to but we need first to decide if we care about usability and the developer experience at all. >> >> This fantastic talk from Steve Krug exposes what's the least you can do for the usability of any software. >> >> http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-abou… >> >> sebastian >> >> o/ >> >> >> >> >> > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

Jan. 3, 2014

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Tudor Girba

Hi Sebastian, I think you read my mail too literally :). We do not disagree. My comment about "Don't make me think" is that what applies for the web is not quite the same as for a programming environment. For example, on the web, it is more profitable to assume that everyone is a newcomer, while in a tool where you spend a lot of time this is not necessarily the case. That said, of course, doing usability experiments is indeed useful (and hard to grasp :)). I did not argue against that. It would be great to start any effort in this direction. Cheers, Doru On Fri, Jan 3, 2014 at 12:49 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > Our engineering bias make us think too literally some times. > > Let's stay scientific but use the designer hat instead of the > mathematician hat. > > I know is for the web, but don't you have the feeling that you can design > an experiment in a way that will converge to *the same usability > principles*? > > There are things in Krug's way to document the experiment that could have > the same degree of validity even for hardware devices! > > *Don't make me think, *as usability principle, is the most generous thing > you can do for the user. When you do that, what you are also doing is > saving the user's neocortex energy to solve other problems (their social, > environmental or personal problems). Is how you help them to change their > worlds. That's the closest thing to your mission accomplished. > > Cheap idea for us: > > 1. Design a simple experiment. And yes, simple *for* *them* is not the > same as simple for you! > 2. One morning per month (maybe that's too much, one every 3 months would > be a huge leap forward) > 3. Take 3 or 4 computer science students unfamiliar to Pharo, I'll say > that's the adequate audience > 4. Bribe them to participate with a cappuccino with croissants or something > 5. During the experiment, ask them *what are you thinking now* every time > their flow is interrupted > 6. Discover their assumptions. Don't explain. Listen! (and document). Take > notes like crazy* > 7. Don't panic by overwhelming issues. Discuss with colleagues or publish > in a private wiki for the team or something > 8. Decide what are the 3 most blocking entry barriers and show that to the > team. We need to discuss *the discovered issues* do, together, something > about them > > > *Your mission here is not educate the guys, only to document which are *their > assumptions*. You might feel frustrated by the state of education today > or the poor preparation they had or the bad influence of industry vices or > how anxious and distracted young people are these days. Nothing about that > should change your mission of *discovering their assumptions, *so the > best is to ask them, listen, document and share with maintainers. > > > > > On Jan 3, 2014, at 7:48 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Thanks for bringing this up. > > Yes, we should care about usability. > > And I agree that usability is attainable as long as you approach it with > consistent discipline. It's similar to designing code: you start asking > questions, figure out what the right questions are, and then stick to it. > > I like Steve Krug's Don't make me think book. However, please keep in mind > that the lessons in the book apply specifically to the web. An environment > like Pharo should not obey exactly the same things. > > But, as Esteban says, let's focus on the future, and keep usability high > in our list of concerns. Even if we might not know how to do it now, simply > sticking with it will make us better in the long run. > > Cheers, > Doru > > > > > On Fri, Jan 3, 2014 at 10:38 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> Hi Sebastian, >> >> I feel your pain :) >> >> we are aiming to focus Pharo 4 in âmodularisation and toolsâ, to enhance >> what we have currently. >> Nowâ¦ one of the biggest problems we have is that people is so used to the >> old tools that they donât even realise that we can do a lot better. And >> most possible some people will react violently to any changeâ¦ but well, we >> will do it anyway, with your help. >> Letâs all together build a better IDE for the future :) >> >> Esteban >> >> On 03 Jan 2014, at 01:13, Sebastian Sastre <sebastian(a)flowingconcept.com> >> wrote: >> >> Guys is no mystery that we have some issues with UI. >> >> It's not so bad either, we have many things that are light years ahead of >> other but we consistently miss some really basic stuff from the >> Human-Computer-Interactcion point of view. >> >> The community is biased towards engineering and unbalanced regarding to >> design so this is no surprise (why this happens is another interesting >> conversation). >> >> UI is not that hard when you know what to pay attention to but we need >> first to decide if we care about usability and the developer experience at >> all. >> >> This fantastic talk from Steve Krug exposes what's the least you can do >> for the usability of any software. >> >> >> http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-abou… >> >> sebastian <https://about.me/sebastianconcept> >> >> o/ >> >> >> >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by Frank Shearar

On 3 January 2014 11:44, Otto Behrens <otto(a)finworks.biz> wrote: >> 'Conversion' implies using the resulting String in some further >> computation. 'Printing' usually implies displaying something to the >> user (and nothing more), or serialising to a file/network. > > What kinds of computation are you thinking of regarding a string? I > think I understand what you're saying, I'm just trying to make it a > bit more concrete in my mind. I just mean that sometimes you want to work with a string representation of a thing, and #asString is how you get it. For instance, a Symbol might printString as '#foo' while in its converted form it returns 'foo'. > The requirements of displaying something to the user and serialising > to a file/network are quite different, or not? You're right. I'm wrong in saying that #printString should be used to serialise anything. Actually, you'd probably use #storeString for serialising, if you weren't using Fuel. frank

Jan. 3, 2014

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by J.F. Rick

As somebody coming from the HCI side, rather than the software engineering / programming language side, I too value usability. But, it seems to me that you first do the major changes and then slowly hone to get usability right. I find lots of small little usability bugs in Pharo 3.0 but I assume that those are mainly due to the tools getting majorly upgraded right now. I'm not sure how to report these tiny usability bugs. If someone can chime in on the correct way to report these, I'd be willing to report them. For instance, I notice that when I am writing code in the browser and click to another method, I am no longer warned that my code will be lost. It is simply lost. That's a basic usability thing: Prevent costly errors. But, I assume that this is just a matter of Nautilus still getting refined. So, it may not even be worth mentioning. My main contribution right now is being an early adopter of Athens and sending any weaknesses I find to the list. Athens is new and still has lots of little bugs. At the same time, it is ambitious and a major step forward for Pharo if it can be fully integrated. Of course, these little bugs will get taken care of as Athens is more widely used but part of the excitement of Pharo is that it is evolving. There are some areas where usability honing can be useful but others were the software engineering has to settle down before the honing can start. Cheers, Jeff On Fri, Jan 3, 2014 at 10:48 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks for bringing this up. > > Yes, we should care about usability. > > And I agree that usability is attainable as long as you approach it with > consistent discipline. It's similar to designing code: you start asking > questions, figure out what the right questions are, and then stick to it. > > I like Steve Krug's Don't make me think book. However, please keep in mind > that the lessons in the book apply specifically to the web. An environment > like Pharo should not obey exactly the same things. > > But, as Esteban says, let's focus on the future, and keep usability high > in our list of concerns. Even if we might not know how to do it now, simply > sticking with it will make us better in the long run. > > Cheers, > Doru > > > > > On Fri, Jan 3, 2014 at 10:38 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> Hi Sebastian, >> >> I feel your pain :) >> >> we are aiming to focus Pharo 4 in âmodularisation and toolsâ, to enhance >> what we have currently. >> Nowâ¦ one of the biggest problems we have is that people is so used to the >> old tools that they donât even realise that we can do a lot better. And >> most possible some people will react violently to any changeâ¦ but well, we >> will do it anyway, with your help. >> Letâs all together build a better IDE for the future :) >> >> Esteban >> >> On 03 Jan 2014, at 01:13, Sebastian Sastre <sebastian(a)flowingconcept.com> >> wrote: >> >> Guys is no mystery that we have some issues with UI. >> >> It's not so bad either, we have many things that are light years ahead of >> other but we consistently miss some really basic stuff from the >> Human-Computer-Interactcion point of view. >> >> The community is biased towards engineering and unbalanced regarding to >> design so this is no surprise (why this happens is another interesting >> conversation). >> >> UI is not that hard when you know what to pay attention to but we need >> first to decide if we care about usability and the developer experience at >> all. >> >> This fantastic talk from Steve Krug exposes what's the least you can do >> for the usability of any software. >> >> >> http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-abou… >> >> sebastian <https://about.me/sebastianconcept> >> >> o/ >> >> >> >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Jan. 3, 2014

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Sebastian Sastre

Our engineering bias make us think too literally some times. Let's stay scientific but use the designer hat instead of the mathematician hat. I know is for the web, but don't you have the feeling that you can design an experiment in a way that will converge to the same usability principles? There are things in Krug's way to document the experiment that could have the same degree of validity even for hardware devices! Don't make me think, as usability principle, is the most generous thing you can do for the user. When you do that, what you are also doing is saving the user's neocortex energy to solve other problems (their social, environmental or personal problems). Is how you help them to change their worlds. That's the closest thing to your mission accomplished. Cheap idea for us: 1. Design a simple experiment. And yes, simple for them is not the same as simple for you! 2. One morning per month (maybe that's too much, one every 3 months would be a huge leap forward) 3. Take 3 or 4 computer science students unfamiliar to Pharo, I'll say that's the adequate audience 4. Bribe them to participate with a cappuccino with croissants or something 5. During the experiment, ask them what are you thinking now every time their flow is interrupted 6. Discover their assumptions. Don't explain. Listen! (and document). Take notes like crazy* 7. Don't panic by overwhelming issues. Discuss with colleagues or publish in a private wiki for the team or something 8. Decide what are the 3 most blocking entry barriers and show that to the team. We need to discuss the discovered issues do, together, something about them *Your mission here is not educate the guys, only to document which are their assumptions. You might feel frustrated by the state of education today or the poor preparation they had or the bad influence of industry vices or how anxious and distracted young people are these days. Nothing about that should change your mission of discovering their assumptions, so the best is to ask them, listen, document and share with maintainers. On Jan 3, 2014, at 7:48 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks for bringing this up. > > Yes, we should care about usability. > > And I agree that usability is attainable as long as you approach it with consistent discipline. It's similar to designing code: you start asking questions, figure out what the right questions are, and then stick to it. > > I like Steve Krug's Don't make me think book. However, please keep in mind that the lessons in the book apply specifically to the web. An environment like Pharo should not obey exactly the same things. > > But, as Esteban says, let's focus on the future, and keep usability high in our list of concerns. Even if we might not know how to do it now, simply sticking with it will make us better in the long run. > > Cheers, > Doru > > > > > On Fri, Jan 3, 2014 at 10:38 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Sebastian, > > I feel your pain :) > > we are aiming to focus Pharo 4 in âmodularisation and toolsâ, to enhance what we have currently. > Nowâ¦ one of the biggest problems we have is that people is so used to the old tools that they donât even realise that we can do a lot better. And most possible some people will react violently to any changeâ¦ but well, we will do it anyway, with your help. > Letâs all together build a better IDE for the future :) > > Esteban > > On 03 Jan 2014, at 01:13, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Guys is no mystery that we have some issues with UI. >> >> It's not so bad either, we have many things that are light years ahead of other but we consistently miss some really basic stuff from the Human-Computer-Interactcion point of view. >> >> The community is biased towards engineering and unbalanced regarding to design so this is no surprise (why this happens is another interesting conversation). >> >> UI is not that hard when you know what to pay attention to but we need first to decide if we care about usability and the developer experience at all. >> >> This fantastic talk from Steve Krug exposes what's the least you can do for the usability of any software. >> >> http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-abou… >> >> sebastian >> >> o/ >> >> >> >> >> > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by Otto Behrens

> 'Conversion' implies using the resulting String in some further > computation. 'Printing' usually implies displaying something to the > user (and nothing more), or serialising to a file/network. What kinds of computation are you thinking of regarding a string? I think I understand what you're saying, I'm just trying to make it a bit more concrete in my mind. The requirements of displaying something to the user and serialising to a file/network are quite different, or not? I'm not trying to be disagreeable. I think the systems I've seen have not used these API's consistently. Especially if you see things like #displayString being replaced by #asString. What do we do now?

Jan. 3, 2014