Tudor Girba wrote:
Hi Esteban,
I know it's a usability principle, but usability should also take into account culture. Programmers are not every-day users, and the assumptions we take should adapt to their needs. This is why it is worth exploring what might or might not be needed.
I cannot believe that programmers do not know the shortcuts,
But programmers new to Pharo don't know the shortcuts. Menus enhance the explorability of the system, and lower the cognitive load of remembering everything all at once, and helps with video tutorials. cheers -ben
but I did not consider the case in which people go through multiple virtual boxes to get to the image. This is a legitimate issue, so these actions are back.
Cheers, Doru
On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 04 Oct 2014, at 22:43, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi Hernán,
Thanks for the feedback. Just a question: Was there anything you do like? :)
The rest of the reply is inline.
On Sat, Oct 4, 2014 at 10:10 PM, Hernán Morales Durand <hernan.morales@gmail.com <mailto:hernan.morales@gmail.com>> wrote:
Sorry if following issues were reported. I have seen so many mails about GT that I wanted to try it. These are my first notes and personal tastes, don't take them as negative just want to provide some feedback:
- First weird thing: The Workspace doesn't open a Workspace anymore, it opens a Playground window.
That is because it is still a work in progress.
- When I select code, right click gives no "Copy, Cut, Delete" commands.
This was reported. The menu is missing on purpose. I still have a hard time understanding why a developer needs those menu entries, but we will add them back. Btw, the shortcuts do work.
Is an usability principle: A system should provide visual feedback about what happens and about what it can do. How can we know what can or cannot do the playground? But of course, using menus as documentation is not always a good idea, so⦠we need to find a balance here :) I always use OSX design guidelines as a base on what I want to do (not that we should take it literally, but is always good to see what others with time to invest have to say). And this is all what they say about menus: https://developer.apple.com/library/mac/documentation/userexperience/concept...
Esteban
- Selecting an instance variable from the "State" tab, completely shift the code view and scrolls to a new Inspector. Is not that I would love to scroll back everytime to get a view on my code.
The usage depends on the scenario in which you are. In most cases, when you do want to drill through many objects, you are likely to only use the playground as an entry point. When you build a more elaborate piece of code in the playground, you typically do not need to drill too much. In any case, if you want to scroll back, there are also keybindings that allow you to navigate: Cmd+Alt+Left/Right.
- I cannot find how to close new Inspector tabs.
This is a feature that is already planned.
- "Print it" seems broken. It seems to print evaluation result but suddenly dissapears.
What do you mean? Can you elaborate on that? Print it should behave like here:
- Debugger buttons Into, Through, etc.
-- They are too small and close themselves for the importance they have. -- They have no caption, so you have to mouse over to know what they do (until you get used to) -- They are like "too distant" from the code view.
The debugger is not in the Pharo image, so I think you are trying the Moose image. Is that so? In any case, the positioning of the icons will be the same everywhere in GT (to the right of the scope they relate to). We are still fiddling with the right balance in the debugger.
Cheers, Doru
Cheers,
Hernán
-- www.tudorgirba.com <http://www.tudorgirba.com/>
"Every thing has its own flow"
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"