On Sun, Dec 06, 2015 at 06:36:23PM -0800, Aaron Wolf wrote: > > On 12/06/2015 03:33 PM, mray wrote: >> >> On 06.12.2015 22:12, Aaron Wolf wrote: >>> >>> A mild side-note: it seems semantically wrong to call the top section >>> of the project page an <article>. The pledge button and stats and >>> screen shot are definitely not an article. That needs to be changed. >>> An <article> is like a blog post, it is specifically for actual >>> content that could be stripped out and printed as a piece of writing, >>> an article… >>> >> >> I don't think this is neither the time to change the design, nor the >> time for any kind of side notes. The design does have issues in my eyes, >> too. Let us talk about those after there is an actual page to talk about. >> > > I'm not going to insist and will defer to some degree to others and > their opinions about workflow, but I dislike the idea that we ignore > apparent issues. The idea of fast iteration and agile development is, > well, superior I think, to strict waterfall style work. Effectively, the > idea that we absolutely complete a stage before it moves to the next > stage where other sorts of issues can be addressed is, I think, an old > fashioned and inefficient way to work.
Aaron, it seems like you are arguing against yourself here. There are indeed imperfect elements, but that's ok. We'll iterate and fix them next time. If we stop and hash out every detail about mray's html right now, that would definitely not be agile. Waterfall is slightly different; we wouldn't be waterfalling even if we *did* hash out all the html questions. But still. > Now, it's perfectly fine to say "okay, that concern is noted, but I > think that particular concern should wait until X and Y are done before > we tackle it". I'm not against focusing or having an order to things at > all. I just think there's risk of a lot of excessive work being done if > we close off mentioning various issues and concerns until some point. The alternative risk is spending a lot of time getting every little thing correct, only to realize it will all be thrown away. Being agile is about going all the way through the process, shipping real code, on short timescales. It is not about being flexible with requirements; that follows naturally. It is not about getting every detail right up front; that is anathema. >> Concerning the breadcrumbs in particular: I don't think there is an >> alternative to having one hierarchy - that is the nature of them. >> > > Yes, there must be specifically a clear single-path tree-style hierarchy > for the breadcrumbs. But the breadcrumbs should not include the project > categories, because those should be tags and not part of the hierarchy. I agree here. It seems like projects would basically be a top-level item for breadcrumbs.
signature.asc
Description: Digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
