Marketplace Ideas

  • 1
  • Idea
  • Updated 5 years ago
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 deploying apps, and receivers creating them. (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 their situation.)

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 explorer app. 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

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 is, link to good tutorials, etc.

Faceted search: Consider employing faceted filtering on archive pages. So that when I'm looking at this list of opensource apps, for example, I can filter by the type of function, city where apps are deployed, and so on.
Photo of trunksonline


  • 9 Posts
  • 0 Reply Likes

Posted 5 years ago

  • 1

Be the first to post a reply!