These are my rough criticisms (hopefully constructive!) of

Ok first of all, what is with all of the patterns named ImplementingSomePatternInNET? While I understand that examples of patterns can be very useful, I think it’s clutter to label them separately. ImplementingModelViewControllerInASPNET and ImplementingMVCWithUIP both belong as “Examples” links in the ModelViewController page. I haven’t checked yet, but if there isn’t an Examples section for other patterns, there ought to be, specifically for this purpose. I’m not trying to downplay the usefulness of the MDSN library – I just think it’s been placed at the wrong location.

I see several methods of mapping class hierarchies into a relational model. ClassTableInheritance, ConcreteTableInheritance, and SingleTableInheritance are all solutions to the exact same problem. However, none of them list each other under the “Related Patterns” section. They only link to the book’s page. It would be useful for patterns that are clearly so closely related to be indicated as being such. Maybe this is just an issue of “many eyes” fixing the situation. At the very least, an anonymous user should be able to suggest a relation between two patterns.

I see a few patterns that appear to be specializations on other patterns (noticably MessagingMapper, which looks strikingly like an Adapter). Once again, relations between patterns like these should be expressed, particularly highlighting their differences.

I still don’t like the whole Table approach. First off, why browse by “TableRows”? Couldn’t they just be called [Implementor] Roles? Likewise with TableColumns really meaning something more like Problem Category. The authors suggest that the lack of patterns in certain regions signify a need for more patterns – I say it signifies a bad classification of existing patterns. Roles and Categories definitely need to be modifiable. Additionally, while the Table allows two levels of Roles, only one level of Categories is implied. I recommend a tree-based structure on either axis for classification, to allow whatever level of granularity is necessary.

The vocabulary seems to be problem, as well. I believe there is enough emotion in both Enterprise and Community that it’s not wise to attempt to mix them. Enterprise typically signifies large, inflexible systems with edicts from on high. Look at most Enterprise software and see how fast it reacts to changing environments. Just look at the speed of feature development and bug fixing in small applications (facebook, freeside), in comparison to an Enterprise application (the last one I saw had 4-6 machines involved in a heterogeneous Java-based environment using multiple web / application servers per machine… there was only one installation in the nation where it actually *worked*).

Community, on the other hand, signifies smaller scope and more egalitarian involvement (both typically because of the in-my-spare-time nature). In order for this website to be of any benefit, it should promote Community as a driving force, even at the cost of sacrificing the Enterprise “feeling”. After all, why should patterns be labeled as “Enterprise”? Anything that’s big enough to really deserve the term (clustering, grid computing, yadda yadda) don’t need to be labeled as Enterprise in order to send the message of scope to the user. In fact many of the “Enterprise” techniques I see on this website could be applied in smaller places… so drop the Enterprise. EnterpriseObserver gives about the same meaning as SuperAwesomeObserver.

Ok, time to poke around for more usability-related issues.

First thing I notice is that I had to increase the font size 2 steps on my browser to be able to read anything. Is it my browser? The rest of the Internet looks fine. Default CSS should lay off of the font shrinkage and stick with 1em.

Second thing: the left sidebar.

  • I don’t see a Register link, but it would be useful to see one right by the Login link (separated from the rest of the content, as it is now).
  • Show/Hide Changes don’t belong in the middle of that list. Put that link, along with Printable Version, up in the top right corner of the page, rendered as tabs. The tabs for Topic/Discussion/Edit/History already set a precedent for alternate views of the same content, which is more closely related to Show Changes and Printable Version than any navigational links.
  • What do Subscriptions and Rename mean? I realize I don’t have an account, and maybe it would be really obvious if I did… but I can’t see them without logging in, and it isn’t immediately obvious what they do based on context. I imagine Subscriptions would be some sort of “my favorites” section, in which case it shouldn’t appear at all for anonymous users. If Rename really means “change the name of the current page”, that’s a horrible place to put it. It belongs in the Edit tab for a page. Furthermore, given that page names identify them for wiki linkability, I would expect that no page could actually be renamed (only the titles changed).
  • The icons presented in front of each pattern (signifying the author) are destructive. As was mentioned in our last meeting, they serve to intimidate any community effort (everyone with an icon is published somewhere it seems, implying an eletist attitude: if many people contribute, they can’t possibly dole out enough icons, and that creates a double-standard). Down with the icons, and just leave the Authors page as-is.
  • Goal-based link categories on the front page, please! I propose the following sections
    • For Readers – TheTable, Authors, AllPatterns, PatternLostAndFound, RecentAdditions
    • For Authors – EmptyPatternTemplate, SuggestedEnhancements, AddANewPattern, MicrosoftWikiPatternStyle
    • Learn More – MSDN Architecture Webcast, PatternShare, Contribute