| ||
|
This community works best when people use their real names. Please register for a free account. Links:
» Joel on Software discussion Movie:"Make Better Software" is a 6 movie course designed to help you as you grow from a micro-ISV to a large software company. If you're hiring employee 2 through 200, this movie was created for you! Moderators:
Eric Sink
Bob Walsh |
Hello, I'm a hobbyist programmer turned commercial forum administrator who is now trying to become a serious programmer. I'm betting on Python, Browser GUIs and SQLite. I spent a week or so doing research on what sort of program I can write for busy executives in my country, particularly those who use laptops a lot. After lots of research analysis, I settled on a particular product. My aim is to create a browser-based package that these busy executives will install on their laptops and use regularly. But it turns out that the product I settled on, if properly built, would work quite well as a web application for international use. Does it make sense to exclusively package my product as a browser-based downloadable app sold locally when I know it will work well as a browser-based application? I'm tired of building Adsense-supported websites; I want real customers in order to grow as a business person. That doesn't sound like a rational reason to aviod the web approach, so what's your take on this? Thanks a million!
Sounds like an ideal type thing to do in SilverLight then recycle code for the executives - get the best of both worlds. Just an idea anyways.
Seun, that is exactly what I do with my product - python, django, sqlite all packaged together as a downloadable web app. I believe that model can work. The only thing you need to be careful about is that it is easy to install and setup. If it is for executives, they are not going to spend a lot of time installing and setting up apache and configuring it to run your app. Thats why I package the whole thing as an .exe with a self contained web server as well. I wrote a blog post about it here - http://www.silverstripesoftware.com/blog/archives/51
Sounds like the worst of both worlds to me. The awkwardness of a web interface without the benefits of a web application (no installation, instant updates). The platform hassle of a desktop app without the perk of using native libraries. What leads you to choose this approach?
Pardon me, but what is the fundamental difference between a "browser-based downloadable app" and a "browser-based application"? Is the former a client executable you run on Windows but "Download" from ther internet whereas the latter simply a web app (data store on server)? Thanks.
You don't want to build another AdSense site? Don't build one, sell monthly subscriptions. You get regular income, you don't worry about piracy or fraud because you can pull the plug whenever you want to, and it's probably easier to sell something for, say, $29.95/mo than $350.
"Does it make sense to exclusively package my product as a browser-based downloadable app sold locally when I know it will work well as a browser-based application? " No. 1) With a web app, you make updates on the server and you're done. Every user has the latest version automatically. Downloadable app means somehow pushing patches out to your busy executives' desktops. That means writing a software update mechanism that does this automatically (more work), or convincing the busy executives to sign up for patch notifications by email/web feed and getting them to install them (good luck with that). 2) Busy executives who work in a place with a competent IT department are going to lock their machines down pretty hard. That means arbitrary installers aren't allowed. THAT means extra hurdles for your app to jump before the busy executives ever get the chance to see it. Unless your pitch is really really solid most won't think it worth the time. 3) Busy executives already know how their browser works; they don't know how the UI of your downloadable app works. And on and on. Seriously, web apps are the way to go except in very specific cases (like where you need a richer GUI than a browser can provide, or where client privacy/data privacy is a major concern).
>Why Not Silverlight? It's probably not worth the cost of learning it. My app doesn't really seem to need a rich UI. >What's A Standalone Browser-Based App, Really? It's an application you install locally and then access through your web browser. Like Nettracker Lite, which is the best server log analyser I've ever sed. >Isn't A Standalone Browser-based App The Worst Of Both Worlds? I think it's the best of both worlds, really: the easy-to-understand interface of a web application and the speed and responsiveness and independence of a windows application. The flexibility of the HTML UI makes it easier to tweak (it's declarative, as it should be). >Busy executives already know how their browser works; they don't know how the UI of your downloadable app works. My application is likely to be browser-based, whether standalone or web-based. >Web-based App With Credit Card Subscriptions If I go this route, I'll have to forget about customers in my country, because we hardly have credit cards or paypal here. I'm not confident that I can provide a product that will adequately reflect the needs of people in the first world. The other issue is that Internet penetration in my country is still quite low, and tends to be slow and unreliable. People are not used to paying a subscription fee on top of their hefty Internet access charges. Although, to be sincere, they have a habit of not paying for Desktop software products either. I'm more afraid of the prospect of making a product nobody really wants than making a product that people want but prefer to copy, so I prefer to develop for users I can communicate with properly. I don't think the International community wants to buy software from my country, by the way, so 'm wary of a web subscription model.
1. Decide on a product, then, 2. Decide on a platform. Not t'other way 'round.
my name is here Tuesday, July 31, 2007
"I don't think the International community wants to buy software from my country, by the way, so I'm wary of a web subscription model." And by trying, you lose...? Really, the "International community" buys electronics almost straight out of Taiwan and has personal assistants answering phone calls from Bangladesh. Why won't they buy your product if it's good enough? The only reason to restrict yourself to your local market is if you are cloning a successful application and localizing it for your country.
>> >> Why Not Silverlight? >> It's probably not worth the cost of learning it. My app doesn't really seem to need a rich UI. There are bigger reasons to consider something like Silverlight. You get desktop functionality encapsulated in an isolated container. You can reuse the codebase in both client and web environments. You get simple & concise deployment options. There are good reasons *not* to pursue a new and unproven technology like silverlight but your project sounds like it might be a good fit. +1 for "worst of both worlds" - installing a web server on my machine so I can run a single application? Putting up with the response lag and lack of functionality of a web model? Yuck. Not to mention the maintenance, performance and security issues this approach opens up. +1 for "locked down computers" - If your market is corporate executives they won't have security permissions required to install all of the pieces.
Mr. Blah Tuesday, July 31, 2007
Thanks for your observations. My web server is tiny and written in Python; it requires no installation at all: I could run my software perfectly well with just two files - a standalone exe file and an SQlite database, so the main hurdle (for online customers) is the download time. I think I can keep the download size under 2.8mb (the barest minimum is about 1.38mb). I could create both a standalone version for busy execs with locked down PCs and people who want to run the application on flash drives and an installable version for everyone else. As for the browser GUI being clunky, don't we all prefer Gmail to Outlook Express and the Wikipedia to Encarta? I think for the average business-oriented app the browser GUI is more than enough. A little DHTML here and there could help, of course. The response time for a local browser app can be under one second if the web pages it generates are simple enough...
Seun - Good thread going here, but I'd suggest you question a few of your assumptions: they may be getting in your way. 1. People won't buy software from microISVs in my country. With the exceptions of North Korea, Iraq, Nigeria and Iran I don't think this is a hard and fast rule in the U.S. 2. There aren't enough people online in my country to buy my product. First, define enough. Second, while other software distribution channels may work better in a given country, Online IS a country for all intents and purposes: the number of people online is going in one direction - up. 3. Siverlight is just a fancy UI. Since when is attractive unattractive? Nor does it hurt that Silverlight can compute about 300 times faster than javascript, or that it works without tweaks in IE, FF, Windows and Mac. You might also want to google IronPython +DRL. Something to chew on,
Jason Lefkowitz > Downloadable app means somehow pushing patches out to your busy executives' desktops. Rather, the app is actually the updater, that will check if an Internet connection is available, and if yes, will check if a new version is available and offer to download it before launching the real, main EXE. Yahoo and others have been doing with for a few years now. > That means writing a software update mechanism that does this automatically (more work), or convincing the busy executives to sign up for patch notifications by email/web feed and getting them to install them (good luck with that). Forget about executives updating a piece of software themselves. > 2) Busy executives who work in a place with a competent IT department are going to lock their machines down pretty hard. Delphi to the rescue: SQLite can be compiled statically into the EXE, no extra DLL, OCX, etc. > 3) Busy executives already know how their browser works; they don't know how the UI of your downloadable app works. It's possible to write a fat app whose interface offers the simplicity of a web browser, without the bagage of shipping a web app + web server, and the pain of HTML/HTTP for applications. To the OP: It looks like you decided on using web technology before looking at alternatives.
ZeFred Tuesday, July 31, 2007
Just go with the web app. The desktop is for apps that need extremely rich and responsive UI's, like games and media players. The desktop is dead for everything else.
Tuesday, July 31, 2007
""" Just go with the web app. The desktop is for apps that need extremely rich and responsive UI's, like games and media players. The desktop is dead for everything else. """ And do you have any proof of what you are saying? OP, I think that, in a way of repeating what somebody else said, you must first decide your product then the platform. My little experience with freelance programming taught me that when you are by yourself it's difficult to decide a platform. You, the programmer, know that you can do it in many ways. But the employer already knows the way, and you know the best platform for the job... Product first. Platform second.
>> 1. People won't buy software from microISVs in my country. With the exceptions of North Korea, Iraq, Nigeria and Iran I don't think this is a hard and fast rule in the U.S. That's so funny Bob. A quick link to Seun's site and he tells me he is based in Nigeria. Keep up the good work Seun, you are obviously talented and ambitious and I am sure you will get there. I would +1 for the Silverlight and if you are already using Python then +1 for IronPython. P.S. Your Nairaland site rocks. It gives a real cool insight into what real people in Nigeria are thinking and doing. | |
