We Keep Coding

How can I activate a button on a website in real time only when I specifically choose to?

this one is a bit tricky to explain, but for simplicity's sake, lets say I have a website (it doesn't have to be html or php or anything, I'm comfortable with most languages) where there are two buttons, yes or no. in order to see the buttons, you would need to have an account and login to load the page that loads the buttons (I've done this part). the buttons, for the grand majority of time, would be hidden and deactivated. However, when I somehow send a command from my computer, the buttons would become visible and the user would be able to make a choice. In this case, the transition would have to be in real time, so the user would not have to reload the page to see if the buttons are usable again. I would then be able to deactivate them again and start again.
I've been looking around the net for solutions for this for the past two days but I can't wrap my head around it. the closest I've come is to using socket.io but I think I might be overlooking another solution that I don't even know about. These commands would have to fire from unity3d, and the socket scripts made for it are outdated and difficult to get working. Am I missing something?

Web sockets support the type of functionality you are describing, but before web sockets came along, other techniques, like polling provided the appearance of getting an uninitiated message from the server. This works by essentially repeatedly asking for any changes by the server. Modern day applications that implement sockets will still fall back on polling when necessary. This would be another option to consider.
This site describes it well and this stack overflow answer give a good high level description of outdated techniques and why web sockets are the the way to go if possible...
"To overcome this deficiency, Web app developers can implement a technique called HTTP long polling, where the client polls the server requesting new information. The server holds the request open until new data is available. Once available, the server responds and sends the new information. When the client receives the new information, it immediately sends another request, and the operation is repeated. This effectively emulates a server push feature."

Sending a users actions from one page to another

OK, so I have a basic knowledge of PHP, and I'm fairly advanced in CSS/HTML/JavaScript.
I'm trying to set up a page that when an Admin types a message ("Hello, world!"), all the clients automatically update and display this new message in an H1 element.
How do I get the admin page to "talk" to the client page?
I can use PHP, JavaScript and HTML for this, but I'd rather stick to just HTML and JavaScript as my knowledge in PHP is not the best.
Is this possible, and if so, does anyone know how to do this?
It means a lot to me that you guys are willing to help, so thanks!

We can call this real time notifications too.
I won't teach how to do, but will talk about some solutions and ways to do it.
The Node.JS
The first solution is use a websocket. The PHP isn't the best programming language to work with websockets. Node.JS is a great solution. You can use http://socket.io/.
With Socket.IO you can work with websockets easily. Doing things like that in some minutes.
I recommend you read the article below:
http://www.phpbuilder.com/articles/application-architecture/optimization/creating-real-time-applications-with-php-and-websockets.html
Paid solutions
A great paid solution is the https://pusher.com/. When you work with notifications, the Pusher won't cost cheap, because you can have thousand of visitors in your website. But when you work with a chat, the Pusher is good.
(the Pusher price is based on the connected users of your website, and not the notifications that were sent, that is a big problem when we work with notifications, for example, a small volume of messages, but so many users receiving)
Have many other solutions, but i think Pusher is one of the bests.
PHP Solutions
Elephant.io: http://elephant.io/, you'll make a integration between Node.JS, PHP and Socket.io.
Ratchet: http://socketo.me/, i recommend you read the documentation: http://socketo.me/docs/, really great way to start.
Have many solutions too, but know this 2 above first, they're great.
The solution with the "pure power" of the olders
A little bit unnecessary with the new technologies, but works.
Make a application that send messages and save into the database, after that, basically make a ajax polling updating the messages every 5 seconds, for example, and showing to the user when loads.
Works well, but will consume much of your server, and will update even if the application has no new messages to show. (You can work better with it and avoid this problem).

Best way to make a webpage live and multiuser

I'm building a web app for 'brainstorming.' Here's how it works: essentially, a user can come onto the app, and submit a challenge, or click on one that's already there, then think up ideas to resolve that challenge and post them up. I hacked together a basic example here on couchdb: http://wamoyo.iriscouch.com/ideageneration/_design/IdeaGeneration/attachments%2findex.html
I'm going to rebuild it from scratch and all, and I'm hitting up against a challenge that's very unfamiliar to me. I'd like for multiple users to be able to generate ideas for the same challenge at the same time. Kinda like the way google docs allows multiple people to edit a shared document. I have some preliminary thoughts on how to go about this, but I thought I'd ask the expert network here.
I'm fairly comfortable with AJAX, is there a pure AJAX way to make it live and multiuser? Would there be an enormous benefit to going with node.js? What might be some other options?
Thanks soo much!

There are several approaches in making such web pages, using plain ajax polling, using long polling and using web sockets.
Ajax polling - easy to implement, essentially connecting to server recurrently via javascript timer, retrieve data from server and send it back via regular Ajax.
Advantages: easy to implement, works everywhere
Disadvantages: the updates are not in real-time, the data is exchanged only when the timer ticks.
Long polling - the idea is that the connection stays open until it times out, then the connection is reestablished. Can be tricky to implement because of different settings for request timeouts for different web servers, routers, etc.
Web sockets - part of HTML5 umbrella, works only in fairly modern browsers, the protocol changes often which may cause incompatibilities during development and production. Can be used natively with modern browsers and via a Flash plugin with older ones. This technology is most lightweight, because it doesn't incur all the HTTP overhead. Think of it as bi-directional, full-duplex communication channel between a browser and a web server via TCP.
For a detailed discussion, I recommend reading this good post by Scott Hanselman. It tells the story about SignalR, but is applicable to other server-side frameworks.
There is also a podcast by same author, the guest goes fairly deeply into explaining these technologies. Worth listening, IMO.
To answer your question about node.js, please share us your current server technology, so we could get more insight into your stack.

Live stream 'push' with Ajax

I just found an interesting demo of what can be done with the cappuccino framework;
Push with Cappuccino and Tornado
As far as I understands it, It keeps an async client/server connection, which is great to keep a "content" updated.
I would like to know if there is any way I can do the same thing using JQuery or another library. Cappuccino looks a bit like a all-or-nothing framework.

What you are seeing there is not particular to cappucino or Tornado: its an example of HTTP long-polling to simulate async connections. Essentailly a client makes a request to the server with a very long (or infinite) timeout and the server responds when it has some data.
It's a workaround for the fact that until very recently there was no way for a browser to receive a request from a web-server. This is changing as the most recent web-standards are gaining adoption.
In short, there is nothing to stop you employing this kind of technique in any framework. Take a look at the wikipedia page on Comet for more info.
In your specific case, you might find the answers on this question helpful as they are specific to jQuery.

Client notification, should I use an AJAX Push or Poll?

I am working on a simple notification service that will be used to deliver messages to the users surfing a website. The notifications do not have to be sent in real time but it might be a better user experience if they happened more frequently than say every 5 minutes. The data being sent to and from the client is not very large and it is a straight forward database query to retrieve the data.
In reading other conversations on the topic it would appear that an AJAX push can result in higher server loads. Since I can tolerate longer server delays is it worth while to have the server push notifications or to simply poll.
It is not much harder to implement the push scenario and so I thought I would see what the opinion was here.
Thanks for your help.
EDIT:
I have looked into a simple AJAX Push and implemented a simple demo based on this article by Mike Purvis.
The client load is fairly low at around 5k for the initial version and expected to stay that way for quite some time.
Thank you everyone for your responses. I have decided to go with the polling solution but to wrap it all within a utility library so that if they want to change it later it is easier.

I'm surprised noone here has mentioned long-polling. Long polling means keeping an open connection for a longer period (say 30-60 seconds), and once it's closed, re-opening it again, and simply having the socket/connection listen for responses. This results in less connections (but longer ones), and means that responses are almost immediate (some may have to wait for a new polling connection). I'd like to add that in combination with technologies like NodeJS, this results in a very efficient, and resource-light solution, that is 100% browser compatible across all major browsers and versions, and does not require any additional tech like Comet or Flash.
I realize this is an old question, but thought it might still be useful to provide this information :)

Definitely use push its much cooler. If you just want simple notifications I would use something like StreamHub Push Server to do the heavy-lifting for you. Developing your own Ajax Push functionality is an extremely tricky and rocky road - you have to get it working in all browsers and then handle firewalls and proxies killing keep-alive connections etc... Why re-invent the wheel. Also, it has a similarly low footprint of less than 10K so it should suit if that is a priority for you.

Both have diferent requirements and address diferent scenarios.
If you need realtime updates, like in an online chat, push is a must.
But, if the refresh period is big, as it is in your case (5 minutes), then pool is the appropriate solution. Push, in this case, will require a lot of resource from both the client and the server.
Tip! try to make the page that checks the pool fast and clean, so it doesn't consumes a lot of resources in the server in each request. What I usually do is to keep a flag in memory (like in a session variable) that says if the pool is empty or not... so, I only do havy look in the pool only if it is not empty. When the pool is empty, which is most of the time, the page request runs extremely fast.

Because using a push requires an open HTTP connection to be maintained between your server and each client, I'd go for poll as well - not only is that going to consume a lot of server resources but it's also going to be significantly more tricky to implement as matt b mentioned.
My experience with polling is that if you have a frequent enough polling interval on a busy enough site your web server logs can get flooded with poll requests real quickly.
Edit (2017): I'd say your choices are now are between websockets and long polling (mentioned in another answer). Sounds like long polling might be the right choice based on the way the question mentions that the notifications don't need to be received in real time, an infrequent polling period would be pretty easy to implement and shouldn't be very taxing on your server. Websockets are cool and a great choice for many applications these days, sounds like that might be overkill in this case though.

I would implement a poll just because it sounds simpler to write, and keeping it simple is very valuable.

Not sure if you have taken a look at some of the COMET implementations out there (is that what you mean by AJAX push).
If the user is surfing the site, won't that in effect be requesting information from the server that this notification can piggy-back on?

It's impossible to say whether polling will be more expensive then pushing without knowing how many clients you'll have. I'd recommend polling because:
It sounds like you want to update data about once per minute. Unless notifications are able to arrive at a much faster rate than that, pushing would mean you're keeping an HTTP connection open but seeing very little activity on it.
Polling is built on top of existing HTTP conventions, so any server that talks to web browsers is already ready to respond to ordinary Ajax requests. A Comet– or Flash socket–based solution has different requirements; you'll need something like cometd on the server side and a client-side library that groks server-side push.
So if you needed something heavy-duty to manage a torrent of data and a crapload of clients, I'd recommend Comet. But that doesn't seem to be the case.

There's now a service http://pusherapp.com that is trying to solve this problem once and for all, in a blink. Might be worth checking out. (disclaimer: i am in no way associated with them).

I haven't tried it myself, but some say COMET works and is easier than you think. There's also a Ruby on Rails plug-in called Juggernaut that I've heard talked about highly. Again, I haven't used it, so YMMV, but my understanding is that it takes far fewer resources compared to polling. I believe (can someone confirm?) that COMET is how MacRumorsLive.com delivers live blogging of WWDC Stevenotes.