0

I'm working with an organization who wants to make a site that visualizes accessible government data as graphs. Currently they have an early version created in the form of a web app.

Right now I have some strong reservations about delivering thousands of automatically-generated graphs through a single-page web app. In my mind, a web app:

  • Is best used in cases where users need to repeatedly preform a group of smaller, related tasks. In this case they would most likely be seeking a specific piece of information.
  • Has limited SEO potential. Everyday citizens seeking government statistics usually turn to google first, and therefore may never hit our page.
  • Has a steep learning curve. Doubled with the learning curve of understanding and contextualizing government data - yikes. Non-power users wouldn't likely be using it that often or for any length of time.
  • Has potentially long loading times if, while drilling down, users hit a strata that happens to have hundreds of graphs.

Am I off-base on any of these? Are there any arguments in favor of using a web application to deliver dynamically generated content, from a usability perspective?

Improve this question
5
  • It's not clear to me what you think is the distinction between a "web app" and a "web site". To me your description of what a "web app" is actually sounds like a description of a badly implemented website.
    – Daniel Beck
    Feb 6, 2017 at 15:29
  • I'll admit that I'm not an expert here, so I could be using the wrong terminology. By web app I mean a single page interactive module. When a user wants to view graphs relating to the Parks Department they select it from a drop down, and it loads Parks Department data on the same page, replacing whatever was there before. As opposed to leading them to a dedicated Parks page. Is there a better way to refer to what I'm describing?
    – Drosera
    Feb 6, 2017 at 16:51
  • OK, that is the right term (that's often also called a "SPA" or "single page application"). But three of your four bullet points have nothing to do with whether the info is delivered via a SPA or traditional website -- single-page apps do take some extra work if SEO is a necessary consideration, but the rest of your points could apply equally to any kind of site...
    – Daniel Beck
    Feb 6, 2017 at 16:59
  • @Drosera: You're using the right terminology and asking the right questions. If the organisation only has an application (i.e. software) then it has to connect to original data sources and do all the necessary massaging all over again for every request, because software has no storage of its own---it's just ephemeral bits in memory. So to avoid reinventing the same wheel each and every time, it needs a server of its own, which implies a site hooked to the web, i.e. a web site. Whether that site has a fancy face is immaterial--it's still a web site.
    – MMacD
    Feb 6, 2017 at 17:14
  • Thanks, Daniel and MMacD. Had a chat with the project founder and it seems there's a lot of technical flexibility on what the final product can look like. Also seems like we're a few steps away from making any structural decisions, which is great, because they're open to letting the user needs and resulting requirements drive us in whatever direction we need to go. I'm still a little bit unclear on where the road forks between SPA and traditional website. If anyone has any resources on that point I'd love to take a look.
    – Drosera
    Feb 9, 2017 at 15:36

1 Answer 1

Reset to default
0

Since government data isn't refreshed minute by minute (or if it is, I've never heard about it), producing it fresh each time is a bad idea for the reasons you identified.

So yes, I would argue strongly that it should come from a web site where the data can be cached rather than calculated de novo each time (wow, I get the cauld grues just thinking about the electricity that would waste).

Improve this answer
7
  • Whether the data is cached or generated on the fly has nothing to do with whether the site is a "site" or an "app", does it?
    – Daniel Beck
    Feb 6, 2017 at 15:31
  • I'd think it would. Where would you store the massaged data, if you don't have a physical site?
    – MMacD
    Feb 6, 2017 at 16:06
  • ...on the server? The same place you'd be storing the 'unmassaged' data? Web apps do more work on the client side than traditional websites do, but they still have a server side...
    – Daniel Beck
    Feb 6, 2017 at 16:49
  • And where is the server? Web site, right? I suppose it needn't be a conventional site with a visible public face, but it's still listening on port 80 (or 443), probably, since that's what most handhelds know how to talk to. Not too much ftp to or from handhelds, I shouldn't think. But nowadays I make do with a landline and dsl, so I might be wrong about the ftp.
    – MMacD
    Feb 6, 2017 at 17:04
  • That was exactly my point. Whether the site is delivered as a "web site" (individual pages driven by server data) or a "web app" (single web page using XHR requests for server data) has nothing to do with whether the data is pregenerated and cached or generated on the fly.
    – Daniel Beck
    Feb 6, 2017 at 17:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.