On Feb 3, 2014, at 3:19 PM, Pascal Jasmin <[email protected]> wrote:
I moved this over to chat, since I think that it fits better in terms of design discussions. Previously there was a bit more code involved. At some point it may return. > In terms of distinguishing arrays, the key visual effect should be based on > "is there some leading unobvious rank information?" > You may be right, but to this point my approach has been to show all the information. That way the viewer can extract more meaning through consistency, rather than having things appear when I think they are important. Having said that as designer I am making lots of decisions, which is why your feedback is so valuable in challenging assumptions. > A suggestion for making the display smaller and copyable, would be simpler > styles for results: When I started looking at displaying shapes I came to the conclusion that there is a minimum amount of overhead that is needed to show different shapes distinctly. I think the current text based version is just below this minimum, in that it cannot distinguish the effect of leading zeros in an array's display. This means that smaller in the sense of removing information may not allow you to distinguish differences, but on the other hand when you see the way I have dealt with shapes you may come up with ways that could serve both smaller and distinct (which would be great). As for copying, I think that the environment may need to be looked at for that, since the value and shape information is all in the display it may need a copy or paste text approach to pull off the markup information. > text could be purple (still have the tooltip for ascii value) > x: and r could be blue with the x and r symbol black. > j (imajinary) could as you have it be green. I went with the larger and distinct shading and shapes to be more accessible for those with colour discernment challenges. Having said that coloured text can be different grey values so the text approach might still work...except when I was playing with the shapes with zero values, I found that I needed an atom 'enclosure' to indicate empty space. So at this point I have left the bubbles in. > > floating point and scientific notation could be a dark purple/brown, but > maybe the 'e' numeric symbol could be green. Thanks for mentioning the 'e' notation, I will be putting a span element into my float in the next iteration. From what I can see even though 16b5 can be input I have not yet seen a result that includes a 'b'. As you can tell I am mostly playing with these ideas at this point and have not yet entered the full war of attrition that trying to redesign a interface could soon become. > a result of 1 or 0 could be green too, with all other integers below the > system's word size limit being black. > a list that contains integers and floating point numbers would have the whole > list coloured as floating point. > Just to be clear I am actually using J's foreign conjunction to decide types, so I am not in a position to decide the type of the variable. As you can see from the different types of the value of 1 in the video, the language decides the type to be returned. As an an example *8 returns a 1, but it is an integer 1 which is also boolean. This is significant because *_8 can return _1 which is also integer but not boolean, so monadic * returns integers not boolean. > For arrays that display on one line, a leading red star (*) could precede the > result, with a tooltip showning the count # of the last dimension. Any > leading dimensions could be shown with a red number preceding the *. > The one line arrays that I have seen have mostly been literals that include CR or LF as characters and these would be displayed as a non-printing character within a 1 dimensional array. I have not seen one line displays of multiline arrays in numeric forms. I really haven't delved into symbols and unicode yet so who knows what wonders await there. > Distinguishing a shape of 0 (i.0) vs. atomic (0) and more importantly i.0 0 > (0 0) would be important. So if * denotes the existance of at least one 1 > leading shape, a red dash (-) could indicate at least one 0 leading shape. > Both 1 0 3 $ 2 and 0 1 3 $ 2 do not display. Both of these should have a - > prefix, but only the first one should include a * prefix (to show that it > includes a leading item), imo, even if hovering over either symbol shows the > full rank. I agree with the hovering showing the shape information, but I wonder if the - and * characters may start to create their own noise. Not saying it wouldn't work, but hopefully by next week I'll have a demo of how I have approached displaying shapes. I will certainly consider the ideas that you have presented as I go forward. I think we both share the motivation to go as small as possible with the display information, the real challenge appears when I play around the boundary and find smaller can work in most cases and then later see a case that requires its own little wing. Thanks for the ideas, if you get a chance I'd love to see what you can come up with to address these 'maddening' issues. :) Stay tuned for the next post that I have on shape display, I am sure there will be lots to discuss after that. :) Cheers, bob ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
