3 ms·

I never said that this application shouldn't exist; I just don't see the point in making it a web application And that's exactly what I was responding to. A we

by GHFigs 17y ago

I never said that this application shouldn't exist; I just don't see the point in making it a web application And that's exactly what I was responding to. A web application is somebody else's problem, from start to finish. In this case, everything but the writing. Any other solution has its own constraints and so on that become your problem, which quite often isn't worth the expenditure of attention. What I'm really saying is that this application seems like the perfect candidate for http://mozillalabs.com/prism/ http://mozillalabs.com/prism/ http://fluidapp.com/ http://fluidapp.com/ + 30 seconds.

derefr 17y ago
And you just agreed with me without realizing it, because we're talking past each other. The term "web application" doesn't refer to a technology, but rather a means of access. I never asked "why does this product use HTTP/HTML/CSS", or "why is this product accessible over the network", or anything like that—those are technical questions, and have technical answers. The question I asked was "why is this a web application—meaning, why should this be accessed through a web browser?" Web browsers imply a certain social cognitive model. Prism, and Fluid as well, as you pointed out, are programs written to shift the user's mental image of how the application works, from the social, public, status-seeking "web application" mindset, to the local, safe, tinkering-around "desktop application" one. The fact that these programs exist is a testament to the fact that how a user accesses your application matters to them. Remember, Prism/Fluid apps are still "somebody else's problem"—that's what makes them so great, compared to regular desktop apps. So the question is, why did the developer choose the web mindset, rather than the desktop mindset, when options (Fluid, Prism) are available that nullify the disadvantages of the desktop mindset?
- GHFigs 17y ago
  why should this be accessed through a web browser? I have no idea what kind of answer you're looking for. If not technical then what, philosophical? I never knew that writing a web app required such justification. Especially one as trivial as this. Web browsers imply a certain social cognitive model. Bullshit. Remember that the single most successful kind of web application--the kind which nobody will bat an eye at you for using instead of a desktop application--is email, which is exactly as social regardless of how you access it. There is no "public, status-seeking" mindset to web based email that is missing with desktop email. The web is just an interface in that case. So to with this. * So the question is, why did the developer choose the web mindset, rather than the desktop mindset, when options (Fluid, Prism) are available that nullify the disadvantages of the desktop mindset?* Why should the developer care at all about these? He doesn't have to do anything special for the small number of users who choose to use them.
  - derefr 17y ago
    > If not technical then what, philosophical? Aesthetic. User-experiential. However you want to put it. The thing that makes Facebook different from MySpace, text messages different from push email, isn't technical, it's all in how users think about what they're doing. > There is no "public, status-seeking" mindset to web based email that is missing with desktop email. There is a public, status-seeking mindset inherent in using email—that's why it works so well on the web. It's actually kind of useless to make it a desktop application; it's just a historical accident that it was first incarnated through the desktop metaphor at all. > Why should the developer care at all about these? The point is to hide the fact that the user is using a website, because the user has certain connotations about web sites that he or she doesn't have about desktop applications, even if those desktop applications happen to render HTML over HTTP under the hood. The user should be able to download a desktop application and not know that there's a web application sitting at a URL somewhere that it's just accessing and displaying. For a perfect example of this, look at the iTunes Music Store. It's all HTML—but would it feel the same if you accessed it as a website, rather than through iTunes? People trust iTunes with their credit card information more readily than they trust a website. People are more willing to click a "Buy" button in a desktop app than a website. There are usability studies that prove both of these things. Again, it's about how the user thinks about your service—and by using Fluid or Prism on the developer's side to package your service as a desktop app, you can change how the user thinks about your service, without having to change how your service works internally.
    - GHFigs 17y ago
      Aesthetic. User-experiential. However you want to put it. Which is it? I'm asking you because it's your argument. You're craving a justification for developing a web application that isn't inherently social--that is clear--but it isn't clear why you think there needs to be a reason or what answer could possibly suffice. There is a public, status-seeking mindset inherent in using email—that's why it works so well on the web. It's actually kind of useless to make it a desktop application; it's just a historical accident that it was first incarnated through the desktop metaphor at all. With all due respect, this is a giant pile of bullshit. Every bit of it. You're just taking what I said and turning it around rather than actually explaining how the web has an inherently social cognitive model. Of course email is social--I pointed that out myself--but it was social long before the web even existed. You've made no connection between the task and the supposed cognitive model. That's the big gaping whole in your argument that I was pointing to. (The bit about desktop email clients being "kind of useless" is just ignorant, and a pointless tangent, so I won't waste words.) The user should be able to download a desktop application and not know that there's a web application sitting at a URL somewhere that it's just accessing and displaying. ...but why? And more specifically...why should this developer do that for this application? the iTunes Music Store. It's all HTML It isn't, actually, and the degree to which it does is more likely due to technical reasons than people somehow inferring a social or asocial cognitive model. It also helps that, y'know, iTunes is a desktop application, and that for the first several years the store existed, iTunes was explicitly required to play the music the store sold. Incidentally, it also is not accessible from the web, except in a different form, making it a poor example of a web application. I'm not clear on what this is supposed to be a "perfect example" of, other than something completely unrelated to the site in question. Yeah, yeah, I get that desktop apps and web apps are different, but please, get to the point. you can change how the user thinks about your service ...but why? Do you have usability studies to back up the idea that only 'social' applications should be on the web, and that 'non-social' applications, even if they are web-based, should be desktop applications?

by GHFigs 17y ago

derefr 17y ago

And you just agreed with me without realizing it, because we're talking past each other. The term "web application" doesn't refer to a technology, but rather a means of access. I never asked "why does this product use HTTP/HTML/CSS", or "why is this product accessible over the network", or anything like that—those are technical questions, and have technical answers. The question I asked was "why is this a web application—meaning, why should this be accessed through a web browser?" Web browsers imply a certain social cognitive model. Prism, and Fluid as well, as you pointed out, are programs written to shift the user's mental image of how the application works, from the social, public, status-seeking "web application" mindset, to the local, safe, tinkering-around "desktop application" one. The fact that these programs exist is a testament to the fact that how a user accesses your application matters to them. Remember, Prism/Fluid apps are still "somebody else's problem"—that's what makes them so great, compared to regular desktop apps. So the question is, why did the developer choose the web mindset, rather than the desktop mindset, when options (Fluid, Prism) are available that nullify the disadvantages of the desktop mindset?

GHFigs 17y ago
why should this be accessed through a web browser? I have no idea what kind of answer you're looking for. If not technical then what, philosophical? I never knew that writing a web app required such justification. Especially one as trivial as this. Web browsers imply a certain social cognitive model. Bullshit. Remember that the single most successful kind of web application--the kind which nobody will bat an eye at you for using instead of a desktop application--is email, which is exactly as social regardless of how you access it. There is no "public, status-seeking" mindset to web based email that is missing with desktop email. The web is just an interface in that case. So to with this. * So the question is, why did the developer choose the web mindset, rather than the desktop mindset, when options (Fluid, Prism) are available that nullify the disadvantages of the desktop mindset?* Why should the developer care at all about these? He doesn't have to do anything special for the small number of users who choose to use them.
- derefr 17y ago
  > If not technical then what, philosophical? Aesthetic. User-experiential. However you want to put it. The thing that makes Facebook different from MySpace, text messages different from push email, isn't technical, it's all in how users think about what they're doing. > There is no "public, status-seeking" mindset to web based email that is missing with desktop email. There is a public, status-seeking mindset inherent in using email—that's why it works so well on the web. It's actually kind of useless to make it a desktop application; it's just a historical accident that it was first incarnated through the desktop metaphor at all. > Why should the developer care at all about these? The point is to hide the fact that the user is using a website, because the user has certain connotations about web sites that he or she doesn't have about desktop applications, even if those desktop applications happen to render HTML over HTTP under the hood. The user should be able to download a desktop application and not know that there's a web application sitting at a URL somewhere that it's just accessing and displaying. For a perfect example of this, look at the iTunes Music Store. It's all HTML—but would it feel the same if you accessed it as a website, rather than through iTunes? People trust iTunes with their credit card information more readily than they trust a website. People are more willing to click a "Buy" button in a desktop app than a website. There are usability studies that prove both of these things. Again, it's about how the user thinks about your service—and by using Fluid or Prism on the developer's side to package your service as a desktop app, you can change how the user thinks about your service, without having to change how your service works internally.
  - GHFigs 17y ago
    Aesthetic. User-experiential. However you want to put it. Which is it? I'm asking you because it's your argument. You're craving a justification for developing a web application that isn't inherently social--that is clear--but it isn't clear why you think there needs to be a reason or what answer could possibly suffice. There is a public, status-seeking mindset inherent in using email—that's why it works so well on the web. It's actually kind of useless to make it a desktop application; it's just a historical accident that it was first incarnated through the desktop metaphor at all. With all due respect, this is a giant pile of bullshit. Every bit of it. You're just taking what I said and turning it around rather than actually explaining how the web has an inherently social cognitive model. Of course email is social--I pointed that out myself--but it was social long before the web even existed. You've made no connection between the task and the supposed cognitive model. That's the big gaping whole in your argument that I was pointing to. (The bit about desktop email clients being "kind of useless" is just ignorant, and a pointless tangent, so I won't waste words.) The user should be able to download a desktop application and not know that there's a web application sitting at a URL somewhere that it's just accessing and displaying. ...but why? And more specifically...why should this developer do that for this application? the iTunes Music Store. It's all HTML It isn't, actually, and the degree to which it does is more likely due to technical reasons than people somehow inferring a social or asocial cognitive model. It also helps that, y'know, iTunes is a desktop application, and that for the first several years the store existed, iTunes was explicitly required to play the music the store sold. Incidentally, it also is not accessible from the web, except in a different form, making it a poor example of a web application. I'm not clear on what this is supposed to be a "perfect example" of, other than something completely unrelated to the site in question. Yeah, yeah, I get that desktop apps and web apps are different, but please, get to the point. you can change how the user thinks about your service ...but why? Do you have usability studies to back up the idea that only 'social' applications should be on the web, and that 'non-social' applications, even if they are web-based, should be desktop applications?