From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4d30561ec4fd4a26b45150a2416c002a@9srv.net> Date: Wed, 2 Jun 2004 09:20:19 -0400 From: a@9srv.net To: 9fans@cse.psu.edu Subject: Re: [9fans] acme design In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 903dbf1a-eacd-11e9-9e20-41e7f4b1d025 maybe, but i still don't get it. :-) or maybe i do and i'm in denial. i see two "content" frames, a tag frame, and a command frame. what determines which content frame the commands operate on? how do i know which "content" frame is which in the tag list? this model seems to eliminate the tag bar as distinct from the "normal" frames (which seems good - they break the "all text is equal" theme that's present elsewhere) but then introduces several (at least two, possibly more i can't see) new types of "special" frames. this adds more modes to the operation of the interface, which is bad. it also significantly increases the amount of mouse motion needed to execute Tag items (even assuming some magic AI for tracking which frame you're talking about). what is it you think this model gains you? (i'd like to see either multi-line or scrolling Tags, to avoid loosing bits when the Tag gets too long, and the ability to create Rows at the top-level like i can with Cols. these are certainly more incremental (an thus possibly less exciting) than your suggestion, but i'm pretty sure i can clearly show the benefits.)