Hey there, awesome job with the beta launch. Very impressive.
Here's a bit of feedback, loosely organized by section.
Gov-Agency hierachies: You're already getting people entering in county
government and departments. For this thing to be useful, you need the
departments.. that's where the rubbed meets the road. But it's also useful
to know what gov departments belong to. So you might want to develop a
hierchical taxonomy of sorts - arlington county -> arlington county office
of emergency management.
Individual creators: Is there a way of adding individuals? Derek Eder and a
few other folks created
not the City of Chicago, but not as part of an organization. In fact, most
of the stuff coming out of hackathons is by individuals. Since the goal
seems to be to catalogue robust, reliable apps, maybe you don't want a lot
of one-off hackathon apps on there, but it's still something to think
about. At the very least, it would be useful to attach names and twitter
handles to apps, to promote interaction and community.
Agency vs. Development Shop roles: you might want to make the roles a
little easier to interpret, because you've already got makers
and receivers creating
(sure, sometimes gov will created stuff. but to get clean, useful data you
might want to explain the distinctions clearly, and design the data entry
forms in a way that promote accurate info. maybe make people specify org
type: gov agency and developer.)
Apps in city view: Currently when the city view lists the apps that were
made there. While this is certainly useful and good to know, won't it be
more useful, down the line, to see what apps are currently deployed there?
You could probably use tabs and have both.
Data portal link: It would be useful to link to a city's data portal, if
available, prominently at the top of the city page.
App types - inner or outward facing: Some of the apps on here were made
with open data - gov as platform. Some of them, though, are designed to
improve the business processes of government - smarter gov. I think it
would be useful to distinguish the two in the design, both to introduce the
distinction, and to make the marketplace more useful (for example, a lot of
gov users will want to know what's out there that can apply directly to
Highlight open source: the earlier "civic stack" incarnation of this wiki
highlighted only open source apps. This marketplace also features
commercial software, which seems like a good idea. However, since your
mission (and the opengov movement's) is to promote the development and
deployment of open source, I think this should be clear in the design
itself... open source apps should be visually distinguished.)
Good apps vs. All apps in use: A related issue...iIs the goal to catalogue
any and all software currently in use by government, or just highlight to
good stuff? The upside of the "list everything" approach is that it will
let people discover what government functions/software/needs are even out
there. For example, while browsing OpenDataPhilly, I ran into this parcel
It's craptastic, but now I know that parcel explorers are even a thing.
If the goal is to improve government, this kind of granular knowledge of
the nuts and bolts is enormously important and has been lacking in the
opengov movement - lots of focus on tech, which is great, but not nearly
enough on gov.
The downside is clutter and the promotion of crappy apps. Maybe the
solution is listing only the good apps, but adding "app types" or
"businesses processes" to your data model. This way, people can get a sense
for what apps COULD be developed, and we can develop a better taxonomy for
describing the apps themselves. the function categories are great but
pretty broad.. we need names for classes of applications - CRM, CMS,
open311, etc. That would make it easier to build the following feature:
Software alternatives: when an app is a competitor to another app, that
should be in the profile somewhere, something like http://alternativeto.net/
ARCHIVES (for lack of better term)
Editable requirements, software_delivery_method etc. pages: might be useful
to make archive pages for things like requirements and
software_delivery_methods also editable, so I can explain to non-techies
what open layers<http://marketplace.civiccommons.org/requirements/openlayers>
link to good tutorials, etc.
Faceted search: Consider employing faceted
archive pages. So that when I'm looking at this list of opensource
for example, I can filter by the type of function, city where apps are
deployed, and so on.
Let me know if you want to chat about any of these,
- Juan-Pablo Velez