Comments for Mumblings of a Web Developer http://www.nathanderksen.com/blog 'Dis, 'dat, and the other thing Sat, 11 Oct 2008 01:15:35 +0000 http://wordpress.org/?v=2.6 Comment on Playing with AS3 - An example MP3 player component by Nathan Derksen http://www.nathanderksen.com/blog/2006/07/25/playing-with-as3-an-example-mp3-player-component/#comment-29074 Nathan Derksen Tue, 12 Aug 2008 16:57:18 +0000 http://www.nathanderksen.com/blog/2006/07/25/playing-with-as3-an-example-mp3-player-component/#comment-29074 Howdy, sorry missed your note. There is nothing wrong with doing that, I do it myself when I need to access something frequently. I just don't like having too many handles hanging around. Howdy, sorry missed your note. There is nothing wrong with doing that, I do it myself when I need to access something frequently. I just don’t like having too many handles hanging around.

]]> Comment on Playing with AS3 - An example MP3 player component by Mark http://www.nathanderksen.com/blog/2006/07/25/playing-with-as3-an-example-mp3-player-component/#comment-28831 Mark Mon, 28 Jul 2008 22:33:11 +0000 http://www.nathanderksen.com/blog/2006/07/25/playing-with-as3-an-example-mp3-player-component/#comment-28831 Hi. Can you tell me why you do not save references to the elements in a Display Object? (eg. Progressbar). Instead you always lookup up elements by getChildByName(). I don't wanna say its not good to do so... i'm just curious. memory concerns? Hi.
Can you tell me why you do not save references to the elements in a Display Object?
(eg. Progressbar). Instead you always lookup up elements by getChildByName().

I don’t wanna say its not good to do so… i’m just curious. memory concerns?

]]> Comment on It’s official, I’m an author! by apple http://www.nathanderksen.com/blog/2006/04/06/its-official-im-an-author/#comment-18955 apple Tue, 06 Nov 2007 05:18:10 +0000 http://www.nathanderksen.com/blog/?p=27#comment-18955 so worried,我才在当当网买了你的书,当然是中文版的.才开始看呢,老板就要叫我作一个flash游戏动画!!我以前只作一些美工,还有旗帜广告条之类的,现在叫我如何是好??现在叫我作游戏耶,晕~~~~你这一本书这么厚,我选了好久才选到的,看完再作是不可能的了,我好想抱着这本书哭啊~~~~~~~~ I want to ask you, you learn the as2.0 used how long? and do you understand the Chinese? You are so erudite! I hope that 有一天我能和你一样~~~~~~~~~~ so worried,我才在当当网买了你的书,当然是中文版的.才开始看呢,老板就要叫我作一个flash游戏动画!!我以前只作一些美工,还有旗帜广告条之类的,现在叫我如何是好??现在叫我作游戏耶,晕~~~~你这一本书这么厚,我选了好久才选到的,看完再作是不可能的了,我好想抱着这本书哭啊~~~~~~~~
I want to ask you, you learn the as2.0 used how long? and do you understand the Chinese?
You are so erudite! I hope that 有一天我能和你一样~~~~~~~~~~

]]> Comment on Playing with AS3 - An example MP3 player component by cris http://www.nathanderksen.com/blog/2006/07/25/playing-with-as3-an-example-mp3-player-component/#comment-18747 cris Tue, 16 Oct 2007 00:39:21 +0000 http://www.nathanderksen.com/blog/2006/07/25/playing-with-as3-an-example-mp3-player-component/#comment-18747 what is the example mp3 code true html? what is the example mp3 code true html?

]]> Comment on Adobe previews Thermo for creating RIAs by Nathan Derksen http://www.nathanderksen.com/blog/2007/10/03/adobe-previews-thermo-for-creating-rias/#comment-18229 Nathan Derksen Fri, 05 Oct 2007 20:33:17 +0000 http://www.nathanderksen.com/blog/2007/10/03/adobe-previews-thermo-for-creating-rias/#comment-18229 True enough, however if you consider how long it would likely take to do this kind of stuff from scratch, there still could be a substantial benefit. That's why allowing Cairngorm-friendly code would make a lot of sense - it would already be structured in a way that's easy for a developer to go and tweak. True enough, however if you consider how long it would likely take to do this kind of stuff from scratch, there still could be a substantial benefit. That’s why allowing Cairngorm-friendly code would make a lot of sense - it would already be structured in a way that’s easy for a developer to go and tweak.

]]> Comment on Adobe previews Thermo for creating RIAs by Ramon Garcia http://www.nathanderksen.com/blog/2007/10/03/adobe-previews-thermo-for-creating-rias/#comment-18075 Ramon Garcia Thu, 04 Oct 2007 04:41:09 +0000 http://www.nathanderksen.com/blog/2007/10/03/adobe-previews-thermo-for-creating-rias/#comment-18075 More code automation tools. Although Adobe is not as bad as Microsoft in this regard, it's still a hassle to have to reword code that was supposedly placed there to make a guy's life easier. More code automation tools. Although Adobe is not as bad as Microsoft in this regard, it’s still a hassle to have to reword code that was supposedly placed there to make a guy’s life easier.

]]> Comment on Adobe previews Thermo for creating RIAs by Adobe previews Thermo for creating RIAs http://www.nathanderksen.com/blog/2007/10/03/adobe-previews-thermo-for-creating-rias/#comment-18074 Adobe previews Thermo for creating RIAs Wed, 03 Oct 2007 20:54:06 +0000 http://www.nathanderksen.com/blog/2007/10/03/adobe-previews-thermo-for-creating-rias/#comment-18074 [...] You can read the rest of this blog post by going to the original source, here [...] [...] You can read the rest of this blog post by going to the original source, here [...]

]]> Comment on Using ASFunction to Call Class Methods by Gunjan kumar http://www.nathanderksen.com/blog/2005/10/18/using-asfunction-to-call-class-methods/#comment-17181 Gunjan kumar Fri, 21 Sep 2007 15:17:03 +0000 http://www.nathanderksen.com/blog/?p=20#comment-17181 Thanks, it is great :- It has given me the way how to use asfunction in custom classes. Just create the function on the same destination where the text is ....great Thanks, it is great :-
It has given me the way how to use asfunction in custom classes. Just create the function on the same destination where the text is ….great

]]> Comment on The keyboard and mouse as input devices by Nathan Derksen http://www.nathanderksen.com/blog/2007/07/09/the-keyboard-and-mouse-as-input-devices/#comment-14597 Nathan Derksen Sun, 15 Jul 2007 21:21:25 +0000 http://www.nathanderksen.com/blog/2007/07/09/the-keyboard-and-mouse-as-input-devices/#comment-14597 Thanks for your reply. I don't think the radio example is evidence against what I described as having potentially too many items. First, there is the difference in quantity of menu items, second is the translation from a tactile interface to a screen interface. 1) With the radio, the physical size of the radio imposes a fixed limit on how many items are accessible. There is a trade-off between having more items and fewer modes vs having an overwhelming number of buttons. There comes a point where the number of buttons makes it hard to find stuff, so while having more buttons may make better use of muscle memory and reduce modal errors, there is a reasonable limit to where it becomes silly with the number of buttons. At that point, you need to decide which features are really important. Modes are a symptom of trying to fit too many features into a device. 2) A tactile interface has more opportunity for differentiating controls than does a screen menu. In addition to grouping, colour, and labels, they can also take advantage of button shape, texture, and haptic feedback. Control positioning on a physical device also provides clues as to its function. An on-screen menu can potentially have a couple of hundred items representing a diverse and unrelated set of functions. Searching and mnemonics certainly help, but can not match a physical device, which can be designed to be operated by touch alone. I did see the search thing, and that's what reminded me of Quicksilver. That's a great feature and I was not criticizing that. The criticism comes more from having too many items crammed on screen. What happens when an application has hundreds of menu items? That's where Quicksilver is cleaner, as it doesn't attempt to show everything, it shows just what matches what you typed. Still, I think that's a hack to a larger problem: having applications which have so many features, many of which are not necessary or could be more cleanly grouped with other things. A fundamental flaw to our interfaces is the need to sell the next version of any given software package, with each one adding more and more features that constantly add to the UI. Thanks for your reply. I don’t think the radio example is evidence against what I described as having potentially too many items. First, there is the difference in quantity of menu items, second is the translation from a tactile interface to a screen interface.

1) With the radio, the physical size of the radio imposes a fixed limit on how many items are accessible. There is a trade-off between having more items and fewer modes vs having an overwhelming number of buttons. There comes a point where the number of buttons makes it hard to find stuff, so while having more buttons may make better use of muscle memory and reduce modal errors, there is a reasonable limit to where it becomes silly with the number of buttons. At that point, you need to decide which features are really important. Modes are a symptom of trying to fit too many features into a device.

2) A tactile interface has more opportunity for differentiating controls than does a screen menu. In addition to grouping, colour, and labels, they can also take advantage of button shape, texture, and haptic feedback. Control positioning on a physical device also provides clues as to its function. An on-screen menu can potentially have a couple of hundred items representing a diverse and unrelated set of functions. Searching and mnemonics certainly help, but can not match a physical device, which can be designed to be operated by touch alone.

I did see the search thing, and that’s what reminded me of Quicksilver. That’s a great feature and I was not criticizing that. The criticism comes more from having too many items crammed on screen. What happens when an application has hundreds of menu items? That’s where Quicksilver is cleaner, as it doesn’t attempt to show everything, it shows just what matches what you typed. Still, I think that’s a hack to a larger problem: having applications which have so many features, many of which are not necessary or could be more cleanly grouped with other things. A fundamental flaw to our interfaces is the need to sell the next version of any given software package, with each one adding more and more features that constantly add to the UI.

]]> Comment on The keyboard and mouse as input devices by Philip Ganchev http://www.nathanderksen.com/blog/2007/07/09/the-keyboard-and-mouse-as-input-devices/#comment-14587 Philip Ganchev Sat, 14 Jul 2007 21:52:49 +0000 http://www.nathanderksen.com/blog/2007/07/09/the-keyboard-and-mouse-as-input-devices/#comment-14587 The radio example is evidence against your hypothesis that having all the controls would be overwhelming, and there are other examples too. See The Humane Interface. The advantage over Quicksilver's UI is, like any menu, exploration. And, you missed the second part of Clay's suggested UI -- typing commands like "save as" after tapping Alt, rather than Control+Shift+S. The advantage is that it is mnemonic, precise and more constant across applicatoins. The radio example is evidence against your hypothesis that having all the controls would be overwhelming, and there are other examples too. See The Humane Interface. The advantage over Quicksilver’s UI is, like any menu, exploration.

And, you missed the second part of Clay’s suggested UI — typing commands like “save as” after tapping Alt, rather than Control+Shift+S. The advantage is that it is mnemonic, precise and more constant across applicatoins.

]]>