Archive for the ‘Programming’ Category

Learning Python and Ruby

I want to learn Python. Actually, if I recall correctly, I had a quick course on Python at the university, but that was millions of years ago.

So, I want to learn Python. And Django. I plan to make my web site(s) from that. Thing is, I had to choose between Python/Django and Ruby/Ruby on Rails. In the end, Python won over Ruby because 1) it seems more popular, and 2) I like Monty Python. Moot point.

I was flipping through the Python tutorial pages when I had a crazy idea (I must have been too concentrated in my learning).

What if I learned both languages at the same time? You get double the work load, double the brain activity, double the learning curve, and in four years, instead of being a master in one of them, I’ll still be struggling and mixing both. Crazy idea indeed. I like it.

In comparison charts, Python and Ruby are often compared together with PHP. Unless they are comparing the web scripting capabilities, I’m at a loss here. From the little I’ve seen so far, it would be easier to compare Python, Ruby, and EcmaScript. I already know Javascript (which is based on EcmaScript), so I could code and compare functions, and give my comments from there. When I’ll move on to making web pages, I’ll check PHP.

In the following days, weeks, or months, I will compare JavaScript, Python, and Ruby. I will not write tutorials on how to learn these languages, as I assume an easy knowledge of programming (C# or JavaScript will do nicely). That means I will not go into details about operators and other basic stuff that should be fairly easy to learn at a glance.

Categories: Programming Tags: , ,

Sub-Entity UX

I am part of a team to create a laboratory web app, and I was looking at some old pages I made about a year ago, when I was just starting to be comfortable with HTML, CSS, and JavaScript.

These pages were basic entities, and were made of a properties panel, a list of sub-entities, and some other stuff here and there. The images in this post are examples of some designs, and are not what we use.

As I learned more and more about user experience, I began to have a better feel for what a web site should look like, and how it should behave. At first, I was making the edit pages to represent as closely as possible how the entity was created in the database. I now understand how wrong this is, because everything should be oriented to give the user the best experience possible.

I noticed that the sub-entity panels (contacts, locations, and deals) were taking too much space – there was real estate reserved for both the sub-entity selection grid, and the properties panel for the selected sub-entity. The grids were crammed with info that could be useful to see quickly, sometimes needing a horizontal scroll bar.

The way I looked at it, it was possible to give the users the same info, but in a better manner. I got rid of the sub-entity properties panel and placed the editable fields in a modal window, in a simpler way. The grid used to select the sub-entity was reconfigured to be easier on the eyes. But best of all, all the info directly related to the entity could be found in the same grid. Also, if the sub-entity had a list of sub-entities itself, it could still be included in the grid.

Clicking an item would popup the modal window, and hovering could show basic info that the user would want to see without going through the popup.

The worst styling part of all this was to decide how to show the info on mouse hover. I came up with some possibilities, all with some flaws. I didn’t find any that was perfect.

End of Line
That was my second favorite. The info box is floating to the right of the whole line. It takes more horizontal space, but every items are visible. If there is a lot of info, the info box for the last few items can go pretty low.

End of Text
Same as the End of Line, but the info box is floating right at the end of the text. This takes less horizontal space, but can partially hide some items in the list. The info box also keeps moving from item to item, which could be irritating.

Below Text
The worst possibility, in my opinion. It doesn’t take much horizontal space, but completely hides the next few items, meaning you can’t hover from item i+1 to item i+n unless you move the cursor away first. This was also visually displeasing, in addition to being confusing (text appears on other text).

Below Text, with Indent
I also disliked this one. Though the items don’t move from left to right between the items, it really hides the next few. They are still hoverable, but unnerving.

Next to Grid
That was my favorite. It takes the most horizontal space, but the info box can always be found at the same place. The only real flaw I can see is that, since the info box is outside the list, the user can’t move the mouse to it without it closing. I don’t know about other people, but I like to move my cursor around the text I am reading. This also makes the text inside the info box unselectable for copy-pasting.

There was also the question about how to show that the line is selected. Should the blue selection box span the whole line, from edge to edge, or only span the text? I think it feels better if the selection is the whole line. Also, as is more apparent in the case of sub-sub-entities, which are indented, should the whole line still be selected, or only from the beginning of the text? I have had a very hard time getting a semantically-correct list-within-a-list to span from the left edge. I think the whole selected line looks pretty good.

Categories: Programming