The Big To Do List

I realize I am a bit late on this (although I am the only one who has done it so far). Here are my ideas for priorities this semester:
Primary: Refined Properties, Molecules, More Widgets, More Plugins and Plugin Standardization, Custom Code Annotations, More Tools and Options for Tools, Editor Preferences, Resource Locations, Constants, Paths/Workflows, Autoconversion
Secondary: Migrate properties to interfaces, Containers, Dynamic Properties, Different Application Modes, Fluency applet, Timing.

What about everyone else?

I like yours, but I think we might want to refine the primary list down a little further. I was thinking that the top three requirements we need to get done ASAP are:

• Molecules (Of course)
• Widget Connections (To fix the biggest problem people had at the big meeting)
• Tasks (Paths)

The other stuff we need to do, but they're just refinements of what we'd have after these things are in. In fact, someone could take a big chunk of them and work on them one after the other, since they're not individually massive, like the above three.

--Dennis

i'm not sure what to add here as i'm not sure what all the above stuff is. nothing has really come in through the transom since our last meeting. i'm sure you're all busy with fluency and all but nothing's really being posted to the new blogs yet. mark's url post over lunch, then mitch's commit and mark's comment on it related to the blogs are all we've seen so far (not counting the subclipse stuff and blog setup etc), either here or there. maybe you're worried about exposing formative stuff to criticism from me/alek/etc? if so, maybe we could have a convention that things posted in blogs can be read but not commented on by non-developers? and they migrate to some more solid (comment-on-able) place when they're more solid, or something?

basically, i'm in the dark, is what i'm saying.
-gjer

Hmmmm, I agree that we need to narrow the list down but it's hard to do that and I figure we have a lot of people anyway. Since Molecules have already started (I did a bit on that last semester) and they are important, I agree that they should be at the top of the list. Same with the other two items you listed. But what about the others? I would argue that Plugins (more and better standardization) and Widgets (more, more standardization, and the tagging) are the other priorities for now. I'll put deciding on this at the top of the list for this weeks meetings. I want to be able to start posting code changes before this week is out and we need to make sure we all know what is going on and what we are doing.

I'd put tasks/paths lower down on the priority. They're going to be important, but we shouldn't be layering things on until we have a better substrate.

Making widgets with annotations, similarly, can wait until we've done a number of other things related to widgets.

Molecules needs to be early, plugin standardization needs to be early (and I'd be interested in taking that), and getting all the tools working needs to be early, but I'm pretty open to direction past those. To a certain extent it'll make sense to redirect our course after we've gotten the first few high priority tasks done.

one big thing i didn't notice any mention of was comments (and publication of comments) on my beta document and milestone list. that was to be discussed at your last meeting, so i presume it was, but nothing came out the other end. i don't mind if you guys think x is a bad idea or y is a high priority, but i need some kind of feedback from you on what x and y are and what your reasons were for your decisions about them. i also think that abandoning the mailing list entirely might not be an entirely good idea. it helps provide a sense of community of effort that's so far lacking (from my limited pov). this term's 'dream team' is in danger of turning into one of the other teams from last term if communication bandwidth and latency doesn't improve a whole lot more. as iv'e noted several times: i don't care how you do it (whether here, on chat, by phone, or f2f, or whatever) but comm is essential, and i need some kind of window into at least its decisions, and something of their justifications.
-gjer

We discussed in one of the meetings the need to focus on the things that make Fluency different. That means Widgets and Connections. Yes, we need a framework, but that can be finished off quickly (and can be modified in the future as needed, incremental design ftw). So yes, this has a high priority.

However, tasks and paths and easy interaction between widgets and connections is all anyone is ever complaining or even talking about. There are interface builders out there that do colors and text editing and such, and so we need these abilities, but we don't have to spend alot of time on them.

Tagging is either trivial or alot bigger than simply tagging support. Either we put in the backend support only or we put in the backend support and have some sort of UI and then we go on to determine a nice hierarchy, and so on. If it's trivial, it's not a high priority (in the sense that we don't have a UI yet, so...who cares?). If tags are this huge task, and we're going to go the route of true interaction with nice widget searching and user tagging (which I like the idea of and think we should do at some level to get an idea of what it entails and we can get real feedback on), then yes, this has a high priority.

--Dennis

again i must caution everyone that i'm not to be seen as peeing in anyone's soup, because i honestly can't judge your options well yet 'cause i don't really know what you're talking about yet, however, having said that, for this particular issue (or what little i understand of it so far), i support the idea of increasing the flexibility of the framework, if only because it brings us closer to the dream (i stress that this is a dream of mine, not something i'm requiring this term!) of a 'fluency built in fluency'. if we had that, then i could care less what authors think, since they could build or hire their own 'dream fluency' and evolution would then take its natural course. as it is, i have to care right now simply because we don't yet have a fluency with sufficient flexibility that it's ui can be arbitrarily remade by people on the programming-skill level of authors. that's what's forcing us to try to make tough ui tradeoff decisions, and as programmers (or at least as people behind the scenes, whether programmers or designers) we're bad at that, if only because we know too much about how fluency actually works (that, by the way, was the essence fo the chief problem with the first demo this term---dennis knew what the slider really did and the audience could only see the slider and its visual effects). that's the tarpit. that's the deathtrap of all ui design that i want to avoid, or at least minimize. i spent a lot of money adn 3 damned years of my life chasing 'the perfect ui' for a particular medical application. while what we did was quite good, it was pain pain pain (and $ $ $!). and the customers ultimately didn't care anyway. i never want to fall into that trap ever again.
-gjer