I need your advice on this project please

[wildheart25c]

I'd like to develop an application similar to the scribble plugin in the yahoo messenger. Basically, when I start my application, a whiteboard appears before me where me and another user are able to draw or write whatever we want. Every user has his own whiteboard so I can invite a user to draw on my board or just view what I'm doing. In either cases, whatever it is that I'm doing on the board must be seen by the user/viewer in real time. So if I'm drawing a circle, the viewer should be able to see my cursor start from one pointa nd move all the way to another point. Once again, real time!

Of course, if I only invite the user to view my board then he won't be able to do anything to it. The number of cursors appearing on the whiteboard must reflect the number of users that have been invited to draw on it.

I have a background in programming but I have no idea how to do it. I don't know which programming language to use. I don't know if this can be done on a browser or an application that runs on your desktop (connection work done in the background). So I hope you'll be able to advise me on which language or framework or w/e I should pursue. If you could give me some links that I canread and from it decide which language I should use and why, that's be great. I appreciate it.

[djr33]

There are a few things to consider. First, do you want this to be a website or a program? A website will be more limited (at least in the way you must make it, potentially in its features), but a program would be a little less convenient (must be downloaded, etc.).

If you want to use a program, I can't really help you with that. But there are lots of options, so it shouldn't be too hard. You'd need to create a drawing application (or borrow one from an open source library, maybe) then create the communication between the users.

I'll assume you'll be making a website for the rest of this post, although the ideas in general should apply to a program as well.

There are two main components of the project: 1. drawing; 2. communication.

Drawing:
Drawing on the web is difficult because there are few ways to give the user anything that feels like a real drawing program. There are three potential solutions:
1. Use Flash. Flash is designed for interactive graphics with lots of control and it can probably do everything you need. The downsides are that you need to learn Flash (and ActionScript); you would need to buy the program which is expensive (although there are a few alternative programs for making Flash files, they don't usually give anywhere close to the control you'd need for this); and it would only work for users with the Flash plugin, so, for example, Apple device users (iPad, iPhone, etc.) would never be able to use it.
Note: you could also try another plugin, but Flash really is the only competitor at the moment. If all of your users would be willing to install something else (maybe Microsoft Silverlight), then you could try to use that if it would be easier for you. But I don't see any reason not to use Flash, although it technically isn't the only option. Using Java applets is probably the second best option, but they are an old technology and barely used any more, and probably will be more unavailable than Flash. But Java is a full programming language so it would be just like a downloadable program if you need that.
If you want a lot of work and a lot of control, you could also write your own plugin and this would give you almost as much flexibility as making a desktop program. But that's a lot of work, and would require your users to trust you enough to install your plugin.

2. Use an HTML <canvas>. A canvas is a drawing element (just like a <p> is a text element) in HTML, but they're not very popular so a lot of the bugs haven't been worked out. They do function in general, though, but it would be a little harder for you than Flash, which has been used many times for this sort of thing. For your information, here's a recent submission of a drawing canvas for HTML:
http://www.dynamicdrive.com/forums/s...ad.php?t=64934
That's not the limit of what a canvas can do, but it is a fairly impressive script-- the canvas tag just isn't that powerful, although you could certainly try to add some other functions like "draw a rectangle" or "fill with color".

3. Use something else that works on the web. For example, you could try to use small <div> areas with Javascript to draw pixels. Probably a bad idea and will likely crash the browser. But with some creativity you might get something that is acceptable, depending on your needs.
You could also try a serverside solution so that you would be reloading the image from the server each time; for example, PHP has the GD library (and alternatively imagemagick) that can do some impressive things with images-- but it's slow, demands a lot of processing power for larger images (and especially for non-basic operations-- anything you'd add yourself beyond the standard image manipulation functions), and would require refreshing the image any time you click-- so nothing would be real time. You could try to create a Javascript interface that creates a preview of where the real image will appear, but that in itself is complicated.
In short, unless you want to experiment and find a better way to do drawing on the web, I suggest avoiding this.


Communication:
Two users need to be able to communicate with each other. I've already explained how to deal with the drawing component, so now let's think about how to communicate the drawing back and forth. Of course if you use a real image then you could just allow both users to view that same JPEG file or whatever. But that would be very limiting because all changes would be saved onto the image and it wouldn't be truly real-time, just quickly updating. And most importantly, it would be destructive-- there's no way to "undo" from a JPEG, unless you wanted to save an image for every click... a bad idea.
So, the best strategy will be to create some sort of mathematical language to describe the image. The theory behind this will be the same as vector based art. You could use pixel information, but that's the same as using a JPEG file and has the same problems.
So, what is vector art? Well, it uses math (coordinates, sizes, shapes, colors, properties like blurring, etc.) to describe an image. In fact, it's a lot like we see the world-- "add a line from the bottom left to the top right then color it blue and add some dots at several locations around that line". But of course you'd need to develop that language. Or you could look for one that exists, but I really have no idea how well that would work. However, this isn't as horrible as it sounds because you already have to use user input (for example, clicking on point a, dragging to point b) and translate it into an image, so all you'd need to do is save the input in the math language, then use THAT to generate the image, rather than use the image to communicate. Does that make sense?

So now that the actual information you need to communicate is handled, the only step left is how to deal with actually sending it back and forth. For that, luckily it's a very well explored area in web design. You need a chat program.
A chat program consists of a client side language (javascript/ajax, or flash, or a java applet, etc) and a serverside language (PHP, CGI, ASP, etc). Think of the setup like satellite television-- the server bounces the signal from one user to another. The server's job isn't to store the information, but just to forward it from sender to receiver.
There are three ways to approach this:
1. Use a database on the server to store the information. You could use this to archive it as well, but the main use would be to retrieve it in "real time". So you could have the browser constantly asking for new information stored in the database and load that. This would be convenient if you wanted to allow someone to join in to view a picture after it was already started-- if you don't store the data, they'd only have the new information since they joined the "chat"-- only part of the image.
2. Use the server only to "bounce" the information from one user to another. This might require a database too, but it would send the information to the user rather than storing it. The upside here is that you'd waste no space on the server, but everything would be realtime and only realtime.
3. Skip the server completely and directly connect between the users. This is basically not possible on the web (for example, with Javascript), but you can do it in a desktop program. For example, in AOL Instant Messenger, "Direct Connect" to send big files actually links the two IP addresses and sends the file directly without wasting space on AOL's server. All other AIM conversations do bounce off the server. Implementing this on the web would be really hard, although if you're using a plugin like a Java applet, you could look into it.

In short, just look up how chat scripts work, and this will be the same.
Generally, everything on the web works by listening-- the page checks the server for information and gets it if needed. Technically, the server cannot initiate contact with the user, so your script must constantly be listening for new information. This makes writing chat scripts difficult, but once the base "listening" component is active, everything works essentially like "sending" information to the user.

Remember that there are two different kinds of information:
1. "chat messages" (eg, "draw a line")... the actual content.
2. "chat actions" (eg, "join a drawing")... the information about participants and connections.
Remember also that you could send special messages upon request if needed, such as resending all of the messages to a new user so they can build the document.

Of course the server could also act as a place to store files if you want to save the images. Remember that the math language for sending the "chat" messages will work for recreating the images later, using a lot less space than an image format (eg, JPEG).

Finally, when you're doing this, it is really important to think about what kinds of major features you require. Some that are very hard (so worth planning ahead for) include:
1. Saving (eg, as an image file to download)
2. Undo (and how many levels?)

[wildheart25c]

First of all, thank you very much for your reply. Second WOW.

1) Regarding your first question; website or program, I don't know. I was hoping that by knowing which languages to use, that I'd be able to decide if it should be through a browser or a desktop. My first thought was using java applets. The application will launch on desktop and then somehow the application in both users' PC would keep checking the server for signs that the other use is drawing or is finished drawing or something. Basically it's the listening part you explained. I thought about this solution because I'm familiar with java applets. I haven't a clue about programs that draw on a browser.

2) Flash vs Silverlight: Flash is the best but expensive, requires a lot of reading and learning, and isn't supported by Apple (I know .. what are they waiting for?!). Silverlight is the opposite at least as far as I know when it comes to the platforms supported by it. Regarding user's trust, that won't be a problem. I'm sharing this with friends so it's cool. As for writing my own plugin, I believe that after reading my post, it's obvious that my programming abilities are nowhere near it As for processing images, it's like you said, it's slow and requires a lot of power. That's why I mentioned the terms REAL TIME and MONITORING several times. So the best way for me to go I suppose would be silverlight. You asked me about my needs. There's nothing specific really. I just want to be able to use my penpad to draw stuff that's all. Nothing major. I don't even want shapes or colors. Just a black line on a whiteboard that's it. Still think this will require a lot of work?

3)The main problem as you have stated is communicating user actions with one another; REAL TIME MONITORING. Developing my own language is out of the question. I thought that maybe the application simply constantly transmits the location of the cursor and whether the pen is pressed or not and on the other side, the application draws the image for me. I really don't know how yahoo does it. Do they send pictures every second or do what I just mentioned or is it something completely different? I mean thinking about it, it's pretty much the same as using remote desktop applications like join.me and teamviewer. How does the mouse here move when my friend moves it on his side?
As for saving the images, it could be like paint. Paint saves the last 3 strokes I did if I'm not mistaken. You can only undo 3 times. After that, whatever changes were made stay the way they are unless you close the window and not save your work.
So back to my (our? i don't know if this is what you were referring to) idea. You mentioned a mathetical representation of what the user was doing on his side such that it'll be shown on the other side. Well isn't that technical talk for saving the actions of the user and making the other computer repeat those actions? It's like using the java library to draw a line by giving it points only in our case, it's happening every second. Are we on the same page or different books here?

4) sending the information back and forth. I tried working with ajax in the past but didn't get much success. My fault of course. But the first thing I learned about it is that it can be used in the stock market board display and chatting. A chat program was my first attempt but since I never did enough reading and studied ajax properly, it wasn't all that good. I don't fully understand the part about connecting two users together via IP.

5)I still don't feel like I completely grasp what you are telling me. For the most part, you've described this application as part of a browser. You only mentioned JAVA in the case of desktop. You also said that the application's features will be a mjor factor in deciding how to proceed with developing this application. There aren't really any more features than I have described. I want an application where me and my friend can draw on my board together, where I'm given the ability to allow a user to work on my board while another to view it only. There aren't any shapes or colors needed. Nothing special regarding the drawing feature. There is a save, load, undo and redo function. This is it regarding the drawing. Oh, it must support penpad/graphic tablets. That's a MUST. As for the rest of the features of this application, there's nothing major. I'd say the only feature is loading a piece of text on the whiteboard itself like leaving a label on the board representing the time or our names or something.
What do you say? Which is it? Browser or desktop app?

All in all thank you very much for your very long and detailed reply. I feel like I have the beginning of a lead in my hand and I just need to follow it through!

[djr33]

1. Well, whether you want it on the web or in a program would determine the language. If you only have one language available, that could determine which you want, but I'd make my decision based on the end user's experience. It's completely your choice though. Personally I'd like to see a website that can do this and works well. A desktop program wouldn't be that impressive, although it would be useful and might serve your needs.
Java applets are a great tool for this, at least in theory. But remember that they really aren't supported any more than Flash is, and actually probably a lot less. Java applets are also a very old part of the web, and they're really not used any more. They pop up odd security warnings, require complicated installations on some computers, and are just annoying. But they give you about as much power and control as you could want, unlike pretty much anything else on the web. Flash is a close second, but it's true-- Java is the most powerful. And as a bonus you could make a standalone application (exe) or an embedded Java applet for your website if you wanted. That's really the only way to put a "full" programming language into a browser.
But at the same time, I want to emphasize that Java applets are old, annoying and sort of like throwing rocks rather than shooting guns, in terms of web modernity. But they would work.

2. Flash is supported on almost all machines. It's not supported on apple devices, but no alternative is either and all of the alternatives are supported on fewer other computers. So Flash is the best, until something else comes along. At least that's for plugins-- you could just use Javascript and that would, in theory, be supported on almost every device out there. Silverlight is just an example. I'm not recommending it or even sure it could do this. I'm just saying there are non-Flash plugins that are similar to Flash, but none are "better" as far as I know, either in abilities or, certainly, in availability.
As for a lot of work, definitely. It sounds fun though. If you're in a hurry, honestly don't bother with this. But if you have a lot of time for it, it sounds like a great project and you'd learn a lot on the way. Even if your programming skills aren't there yet, that's no reason not to try as long as you don't have a strict deadline.

3. I don't mean a "language" in terms of a programming language. I mean a code to represent images. For example: line.10.50.40.90 could represent a line going from point (10,50) to point (40,90). You MUST have something like this, or you can't communicate between users, except by sending images, but that will be far from "real time". So, yes, just send coordinates, but also information like colors, etc. All you need is a "language" that encodes details about drawing-- nothing complicated like writing your own programming language.
Yes, I think we're talking about the same thing.

4. Ajax is complicated, but it's one of the only real solutions for web-based communication. You can use a desktop language like Java instead if you want, but generally that won't be embedded in the web (except perhaps witha Java applet).
As for an IP, what I mean is that the user's computers would act as servers, both sending and receiving information. This is NOT possible on the web (eg, Javascript/ajax) and would require a real programming language like Java or C#. "By IP" I just meant that they are directly connected and nothing is bouncing off a server at all. Like a phone call, it's direct, rather than going through your server.

5. Well, as I said, I was explaining that assuming you're making a web-based program. You don't need to do that, but if you want to, you'll need to figure out (most of) what I explained in my post. If you want a standalone program, that's a different situation, but it still has the same requirements-- drawing (complete with the mathematical representation of the information) and communication (potentially with a server, or direct communication).

Also, remember that if you want users to be able to "find" each other, you will need a server rather than only direct communication.


If you need true "real time" connections, then there are a few things to remember. First, it's not really possible-- you can come very close to it, but just use google docs for a while and you'll see that once in a while there are delays. It isn't possible, except maybe with an intranet, to get two computers to really be working at exactly the same instant. Assuming that ocassional 1-2 second delays are acceptable, then you'll need to focus on making the drawing render quickly and sending the information as mathematical representations (coordinates, etc) rather than as images because those cannot transfer in real time.


Using alternative input methods (graphic tablets, for example) will make everything harder because they aren't natively supported in some circumstances, such as using Javascript. So you'll need to look at whether Flash (or maybe even Javascript?) does have some way to use this input or whether that input can be seen as mouse input (clicks and drags?). You may end up only able to use it with Java or C#, etc.

It's really your choice if you want a website or a program. A good way to think about that first is to decide who your users will be. Will they be using it on the net? Will they want to have a program?
A program will be more powerful, and a website will be more usable. That's just how it works, and that's the tradeoff for every project, basically.

If you need absolute control, probably a program. But a website, even if slightly limited, might be more popular.

An important question to ask yourself is why, if Yahoo already does this, you need to make it. Is it to be better than Yahoo? Is it to serve a different group? Is it to add to your website? Is it to make money? Etc. And those questions should determine what format it needs to be in the end.


To be clear, this would be a hard project for me. But I know where I'd start with it, and that's what I'm explaining here. There are lots of open questions, and you'll need to do plenty of research to figure things out. But start with these ideas, then make a list of requirements (and resources), and start to figure out what it will look like in the end.

[wildheart25c]

1. Well, whether you want it on the web or in a program would determine the language. If you only have one language available, that could determine which you want, but I'd make my decision based on the end user's experience. It's completely your choice though. Personally I'd like to see a website that can do this and works well. A desktop program wouldn't be that impressive, although it would be useful and might serve your needs.
It's really your choice if you want a website or a program. A good way to think about that first is to decide who your users will be. Will they be using it on the net? Will they want to have a program?
A program will be more powerful, and a website will be more usable. That's just how it works, and that's the tradeoff for every project, basically.
If you need absolute control, probably a program. But a website, even if slightly limited, might be more popular.
An important question to ask yourself is why, if Yahoo already does this, you need to make it. Is it to be better than Yahoo? Is it to serve a different group? Is it to add to your website? Is it to make money? Etc. And those questions should determine what format it needs to be in the end.
To be clear, this would be a hard project for me. But I know where I'd start with it, and that's what I'm explaining here. There are lots of open questions, and you'll need to do plenty of research to figure things out. But start with these ideas, then make a list of requirements (and resources), and start to figure out what it will look like in the end.

1. Why build it when there's yahoo? I just want to build a simpler and slightly different version of the scribbling plugin.

2. As for how many will use it? For generic purposes, I'm going with a large number of users.

3. Who will use it? Any1 and everyone.

4. What will the application do? Draw with a tablet pen and let others either watch me draw or draw along with me on the same board. It's a white board with a few labels, buttons, and colors. There are no shapes and only 3 colors. Like I said, simpler than the yahoo version but different because yahoo's version doesn't restrict your access and limits the number of users to 2 per board.

5. Will it be used on the net or intranet? Internet. No limits. Generic.

6. Will I sell the program? Sure why not. I never thought about it. I just wanted to do this application in the best way there is

7. Browser or Program? I'll answer once our list of options become smaller AND I find out if tablets are supported on browsers. This will be a deciding factor of which way to go. It'll also answer the question of whether the users will want to have a program or not.

8. Requirements and conditions? Real time monitoring. No pressure on user resources. Serves as many users as possible.

9. Priorities? Answered in q7 in order.

10. Resources? I have access to everything I need.

Does this help? I never asked myself these questions to be honest. I only asked myself: Which is the best way to accomplish this task? Something flashy, big, modern, etc. I don't have a deadline or any restrictions. And you were right when you said that it was going to be fun. Even if I stop halfway, I'd have learned a lot. Absolutely right!

Also, why'd you say that? Refer to the bold statement in the quote. And by the way, I don't know how I can get two users to connect directly instead of retrieving their information off a server but I'll leave that until I finalize what I need to start working on this project.

Thank you again!

[djr33]

Good, it seems like you've figured out most of the details.

As for my bold quote above, what I mean is that having certain things (such as this) in an easily accessible website is useful and also interesting technically. Of course it's possible to create a program that can do this (you'd just need to use some sort of remote desktop program and photoshop, even), but that's not groundbreaking. You might want something exactly like that so it would be perfect for your project (and useful), but I would love to see a website with good drawing tools that can be used for "drawing chat" or whatever you want to call this-- it sounds fun and will be technically impressive too.

[wildheart25c]

Well thank you for the encouragement. I see what you mean.

As for "ground breaking", that is exactly what I was thinking. You see, I had intended on using java from the beginning. I have enough experience to see bits and pieces of the code being written in my head. I could see a "path". But then I asked myself: What if there were better paths out there? And this is why I came here. My concern with java is that it uses up a lot of resources. I'll admit that I don't know if it uses up "online/speed" resources but I believe it does because this one time I was looking for a host site to host my JSP app and I recall someone telling me that it's not easy to find because java eats up a lot of resources even online.

Anyways, the fact that I thought of the resources problem made me consider the question I asked even more. What I had planned on doing was reinventing the wheel and probably not even using the appropriate tools for it. So I came here looking for the right path. You said it: exciting. ground breaking. I can confidentally tell you that I'd ignore the "user experience" part if it meant doing something grand (exciting). We agree that it'll definitely be educational (ground breaking). The fact that someone like you said he'd be interested is proof enough that this is neither a small deal or an easy job. Enough said

So if I wanted ground breaking and exciting, I should go with Web apps. But if I asked you to factor in the answers I gave while ignoring the tablet condition, would web apps still be the way to go?

[traq]

a bit late in the conversation, but if you go with the browser-based approach, you might look at peerbind.

[djr33]

Personally, the web approach is more interesting, so if I were doing this project, I'd make a web app.
But as I said before, a real program would offer a lot more flexibility, control and probably stability as well, so it's definitely the "real" solution if you want to make the absolute best app possible-- but it won't work on the web which in itself might be enough of a reason to sacrifice some minor components and use a web based approach.

I can't decide for you, but one way to do it would be to start looking at how to do this online then see if any of the limitations bother you. If not, make it web based. If so, decide if you would rather have a desktop program instead.

So while I'd go with a web app, it sounds to me from what you've said like you're thinking about a desktop program. That's fine and would probably fit your needs well. There are two points to consider though:
1. You still need a website to attract downloaders and participants and in fact it might be harder to get participation without a web interface. Imagine facebook if you had to download a program. (One option here would be to develop both-- a very simple interactive interface for drawing together on the website as a demo, then a much more powerful application to download. More work, but could be great advertising too.)
2. You will also still need a server. Even if you allow your users to send data back and forth directly (rather than through your server), you will need a server that allows them to initially connect, keeps track of who is online, who is in which conversations, and potentially to mirror some data so that if, for example, the internet connection goes out, the drawing isn't lost. Your program is inherently part of the internet, whether it is runs in a browser or in a downloadable program.
These aren't reasons against doing a downloadable program, just pieces to think about.


Finally, just to follow up on something I didn't fully explain earlier, you mentioned that you were confused about the idea of directly connecting to another user by IP address. A server works like this: your computer sends a request then the server returns information. Your computer, by default, can only request information and wait for it. And the server can only send information when requested, or it won't go anywhere useful. So it's not a reciprocal relationship-- the two computers are doing two very different things. Most setups for communicating between to user computers would involve a server to bounce the information off-- when you send information it gets saved on the server (which is listening for incoming requests), then when the other user requests new information the server would send it. It's not "real time" in a technical sense, but this can all take place in under a second. That's how almost all chat programs work.
The alternative is to skip the server and send information directly between two computers-- skip the post office and throw the letter like a frisbee from one house to another. And just like that metaphor, it's not too easy to do. The server is designed to receive requests, while your computer doesn't for security reasons. But you can change that-- you'd need to design software (or use some that already exists) that turns your computer into a basic server... nothing complex like a real HTTP server, just something that can send information back and forth and is listening for new incoming requests. This is how peer to peer networks work, for example. The program has built in some sort of basic server that allows two-way communication. Then you can skip the server.
I don't work with this kind of code, but I know how it works theoretically-- if you want to actually do this, then you'll need to look into how it will all work-- ports, data packets and all that stuff.




Traq, that's an interesting link. I'm a little skeptical about using a JS-only solution for security reasons, but if it's "just for fun", that would be useful.

[[Nicolas]]

I'm sorry if I am too late for this.
But here: http://daba.medianewsonline.com/nwepl.html
More than one person can draw along with you, you just can't see their cursor. It is off of Perrbind as Traq posted above.