My boss wants to draw the local network and then, if you click on one of the computers or roll the mouse over one, he wants to see stuff like RAM, CPU, OS, etc. This has to be done in a browser, more specifically, the intranet's wiki.
One of my coworkers suggested using flash (I am a complete noob but I assume ActionScript is what would be used?) and I think it could also be done in javascript but I dunno. Not sure what would be better.
He wants it to be extensible if possible, so adding another computer later or editing values shouldn't be too hard, though the topology shouldn't change very often. This may be up to me to code a separated way to edit it though, I dunno.
Any thoughts/recommendations?
Up until one of the recent versions of Visio (2003?) there was a very useful network discovery tool that would build the diagram. Then using the Save As HTML option there are a number of different ways to build the clickable diagram.
I'd imagine other network diagrammers can do the same.
This is the easiest way I've ever found to do what you want. The only downside I'm aware of is that the Visio discovery will send a significant number of packets; it can flood a network. However in my opinion if your network is that susceptable to load you want to know ASAP. Preferably with a job you can stop and start at will.
Don;t forget that any process you arrive at should be able to rebuild your diagram regularly, e.g. once a week or a month.
The technology you want might be called an HTML Image Map.
It might be cost-effective to purchase a monitoring system.
OpManager is pretty easy to use and provides the graphing capabilities.
Paessler is less expensive, still details, but doesn't have the graphing capabilities.
Related
I have been learning a bit of jQuery and .Net in VB. I have created a product customize tool of sorts that basically layers up divs and add's text, images etc on top of a tshirt.
I'm stuck on an important stage!
I need to be able to convert the content of the div that wraps all these divs of text and images to one flat image taking into account any CSS that has been applied to it also.
I have heard of things that I could use to screen capture the content of a browser on the server which could be possible for low res thumbs etc, but it sounds a little troublesome! and it would really be nice to create an image of high res.
I have also heard to converting the html to html5 canvas then writing that out... but looks too complicated for me to fathom and browser support is an issue.
Is this possible in .NET?
Perhaps something with javascript could be done?
Any help or guidance in the correct direction would be appreciated!
EDIT:
I'm thinking perhaps I could do with two solutions for this. Ideally I would end up with a normal res jpg/png etc for displaying on the website, But also a print ready high res file would be very desirable as well.
PostScript Printer - I have heard of it but I'm struggling to find a good resource to understand it for a beginner (especially with wiki black out). Perhaps I could create a html page from my div content and send it to print to a EPS file. Anyone know any good tutorials for this?
We did this... about 10 years ago. Interestingly, the tech available really hasn't changed too much.
update - Best Answer
Spreadshirt licenses their product: http://blog.spreadshirt.net/uk/2007/11/27/everyones-a-designer-free-designers-for-premium-partners/
Just license it. Don't do this yourself, unless you have real graphics manipulating and print production experience. I'd say in today's world you're looking at somewhere around 4,000 to 5,000 hours of dev time to duplicate what they did... And that's if you have two top tier people working on it.
Short answer: you can't do it in html.
Slightly longer answer:
It doesn't work in part because you can't screen cap the client side and get the level of resolution needed for production type printing. Modern screen resolution is usually on the order of 100 ppi. For a decent print you really need something between 3 and 6 times that density. Otherwise you'll have lots of pixelation and it will generally look like crap when it comes out.
A different Answer:
Your best bet is to leverage something like SVG (scalable vector graphics) and provide a type of drawing surface to the browser. There are several ways of doing this using Flash (Spreadshirt.com uses this) or Silverlight (not recommended). We used flash and it was pretty good.
You might be able to get away with using HTML 5. Regardless, whatever path you pick is going to be complicated.
Once the user is happy with their drawing and wants to print it out, you create the final file and run a process to convert it to Postscript or whatever format your t-shirt provider needs. The converter (aka RIP software) is going to either take a long time to develop or cost a bunch of money... pick one. (helpful hint: buy it. Back then, we spent around $20k US and it was far cheaper than trying to develop).
Of course, this ignores issues such as color matching and calibration. This was actually our primary problem. Everyone's monitor is slightly different and what looks like red on one machine is pink on another.
And for a little background, we were doing customized wrapping paper. The user added text, selected images from our library or uploaded their own, and picked a pattern. Our prints came out on large-format HP Inkjet printers (36" and 60" wide). Ultimately we spent between $200k and $300k just on dev resources to make it happen... and it did, unfortunately, the price point we had to sell at was too high for the market.
If you can use some server-side tool, check phantomjs. This is a headless webkit browser (with no gui) which can take a page's screenshot, an uses a javascript api. It should do the trick.
Send the whole div with user generated content back to server using ajax call.
Generate an HTML Document on server using 'HtmlTextWriter' class.
Then you can convert that HTML file using external tools like
(1) http://www.officeconvert.com/products_website_to_image.htm#easyhtmlsnapshot
(2) http://html-to-image.acasystems.com/faq-html-to-picture.htm
which are not free tools, but you can use them by creating new Process on server.
The best option I came across is wkhtmltopdf. It comes with a tool called wkhtmltoimage. It uses QtWebKit (A Qt port of the WebKit rendering engine) to render a web page, and converts the result to PDF or image format of your choice, all done at server side.
Because it uses WebKit, it renders everything (images, css and even javascript) just like a modern browser does. In my use case, the results have been very satisfying and are almost identical to what browsers would render.
To start, you may want to look at how to run external tools in .NET:
Execute an external EXE with C#.NET
I have a free web site that streams real-time stock-options data. I want to let users make and then save their own JavaScript-callable tools to interpret options data. Users can invoke these custom tools to help them make their own sell/buy decisions about options.
But I am totally stopped, stymied, dead-ended, and buffaloed as to how to accomplish this. If there were just a few choices, I guess I could stumble around blindfolded (as I am now) and finally hit on one that kind-of worked.
But the choices seem endless:
Let the user write JavaScript tools that I'd then interpret;
Mathematica and like toolsets;
Many statistics packages;
Google spreadsheet API.
And overwhelmingly many more.
If anyone has struggled through the process of giving a user some facility for making statistics and probability tools, how did you finally end up? And would you do it that way again?
Plus, my feature-creeposis and perfectionitis want me to integrate charts, graphs, heat maps, and who knows what else more; or at least to allow later integration of graphics.
Graphics would be nice and sexy: I'd like to drop everything and do graphics. But I have to resist and get something onto the page real soon now.1
Q: What can/should I do to allow and encourage easy, intuitive, secure, and powerful tool construction?
EDIT: I definitely don't mean that I want to invent a whole new system de novo. I only (uh-huh, yeah, that's right; 'only' :-) want to interface with some already-existing JavaScript-callable package.
Thanks so much!
1 Now I know a little bit of how my employers might have felt about me at one time: "aw, c'mahhhhhhhhhn, this feature is just too sexy to leave out."
If you need to get something out the door quickly, the first best stop-gap solution is to give people the ability to export their data to a tool they already know how to use (e.g., Excel) for exactly this purpose. Worry about your own version of the wheel once you've provided some basic short-term solution.
Of course, that's not to marginalize the topic of building a functional, browser-based statistical analysis package, which certainly seems interesting. But to be perfectly honest you might as well come to SO and post "Hey guys, I need to develop a new Operating System for the iPhone. Any ideas?"
;)
How important is it to gracefully degrade or inversely Progressively Enhance the UI experiance? I mean am I going to lose a LOT of business if I don't? Do you practice this concept? Are there any web 1.0 users still left out there?
Please could you also include if you practice this personally and how much time you've spent relative to the entire project. I realize every project is different, I want to get a sense of how much time as a general rule I should be allocating toward this goal.
EDIT
Firstly, i'm looking for guidance around how much time I should be devoting to making my applications run without javascript.
Secondly, the BS term "web 1.0" (...lol... I don't really like it either) works because we all understand that as the iteration before ajax and all its goodness.
Thirdly, the kind of applications I'm describing are the ones we are all building, not Facebook, not Twitter (unless you're from Facebook or Twitter) but service or utitlity programs like a web calendar, or an online todo list or [INSERT YOUR APP HERE].
Progressive enhancement is more a mindset than a particular task that you need to allocate time to. If you're doing it right (and if it's important to you), you should be enhancing the user experience with JavaScript, but not relying on it.
For example, a link will point to a new page, but with JavaScript you'll disable the link and load new content into the current page with Ajax. Start off without JavaScript and progressive enhancement will follow naturally.
Progressive enhancement is not only smart but it is faster and easier to develop.
And at each stage, you almost always have a working fall-back.
Here's what it looks like in a nutshell:
Boss/client approves mock ups.
We code to valid HTML output. At this point, the boss/client can start using the site. Baring any boss/client changes, the HTML is mostly done. The site is usable at this point.
We start tweaking the CSS to make it match the boss/client's graphic expectations. Changes to the HTML are minor, if any.
In parallel, JavaScript is added to do non-critical, but nice, things. (Sort tables, Fancy CSS helping, replace some links with AJAX calls, warn the user -- client-side -- of input problems.)
If any one of these things breaks, the site still works.
Also, little, or usually no, html changes are needed.
First of all, lets not start using bullshit terms like "web 1.0" and "web 2.0" etc, the fact is the web is forever progressing and new websites are starting to use JavaScript to enhance the user experience.
I don't know anyone that doesn't allow their site to gracefully degrade when JavaScript isn't available, this is for the same reason we use semantic markup so screen readers can correctly interpret our websites for users with visual impairment, and whilst the vast majority of your visitors / users won't fall into these categories it's still important to think about the minority.
Will you lose a LOT of business, well that depends on how successful you are now and how badly your site degrades, chances are you probably won't lose any business... but that should not be the measure yo use to decide whether to gracefully degrade a website.
So unless you can come up with a pretty good reason, you should probably use JavaScript for the purposes of progressive enhancement, don't depend too much on it.
:-)
This greatly depends on the nature of your aplication and its data. If it's something that you know will be mostly used via computers, than degrading to non-script version UI wouldn't make any obvious benefit (even loss of money because it will take considerable time to develop). You can always tell people to enable javascript in their browsers (similar to what's done here on Stackoverflow - try disabling script and reload the page). Your app/site should display at least something when there's no Javascript posibility.
But if your application has simple data to display and users should access it frequently wherever they are, than degrading to lesser browsers (without script engines like Opera Mini) is a must. Creating a separate UI will less functionality, but keeping everything in that users need to access is probably your best option. UIs like separate iPhone applications for example...
JavaScript is disabled by a small proportion of web users, but when you start to talk big volumes this can make a difference. For example for 1 million visitors, you can expect more than 10,000 not to be able to user your site.
You should decide how much lost business is worth the additional cost of having a non-JavaScript version of your site.
You can have an approach where the entire site may not work without JavaScript but that some of the core features are there.
I have written pure JavaScript front ends before and started noticing performance decrease when working with large stores of data. I have tried using xml and json, but in both cases, it was a lot for the browser to handle.
That poses my question, which is how much is too much?
You can't know, not exactly and not always. You can make a good guess.
It depends on the browser, OS, RAM, CPU, what else is running at that moment, how fast their connection is, what else they're transferring, etc.
Figure out several situations you expect for your average user, and test those. Add for various best, worst, and interesting (e.g. mobile, tablet) cases.
You can, of course, apply experience and extrapolate from your specific cases, and the answer will change for the future.
But don't fall into the trap of "it works for me!"
I commonly see this with screen resolutions: as those have increased, it's much more popular to have multiple windows visible at the same time. In 1995 it was rare for me to not have something maximized; now fifteen years later, it's exactly the opposite.
Yet sometimes people will design some software or a website, use lower contrast[1], maximize it, and connect to a server on localhost—and that's the only evaluation they do.
[1] Because they know what the text says and don't need to read it themselves, so lower contrast looks aesthetically better.
In my opinion, if you need to stop and think about this issue, then the data is too much. In general you should design your applications so that users with a low-end netbooks and/or slow internet connections are still able to run them. Also keep in my mind that more often than not your application isn't the only page your users are visiting at the same time.
My recommendation is to use Firefox with Firebug to do some measurements. See how long a request takes to complete in a modest configuration. If it takes noticeable time for the browser to render data, then you'd better off doing a redesign.
A good guiding principle should be that instead of worrying about whether the browser can handle the volume of data you're sending it, worry about whether your user can handle it. It all depends on the presentation of course (i.e., a lot of data bound for a visualization tool that'll render a complex graph in a canvas is different than a lot of raw numbers bound for a gigantic table), but in my experience a user's brain reaches data overload before the browser/network/client computer.
It really depends on the form that your external data is going to take in your Javascript. If you want to load all your data at once and keep it in memory as a large object with lots of properties (associative array), then you will find that most current desktops can only handle about 100k entries (with small key-value pairs) before performance really degrades.
If it is possible, you should see if there are ways to only load the data that is needed by the user for a given request / interaction. You can use AJAX to request needed data and prefetch data that you think the user may need.
i want to create a web chat/forum application that is google wave alike.
when one person is typing a new post or embed an image in it other persons are seeing this live.
i have read about different techniques and i feel that long polling and iframe are the most talked about.
so, which one should i use for this application and why? i've read something about that the long polling is great for long update intervals. cause if it's a chat, then it has to request new data for every keystroke..and that is like polling every second when typing. so based on this, i should use iframe so that there is only one connection all the time?
what technology is meebo/google wave using?
Long polling sounds like a good choice for this kind of application, but you might want to consider having some kind of delay/buffer period between key stroke and server callbacks. It doesn't have to be very long (less than a second) to give a serious speed gain.
You might also want to consider using Adobe Flash as a bridge between the client side javascript and your own custom communication protocol. This offers better control and less overhead, but comes with the price of a client side plugin dependency.
Last, but not at least, you might want to consider building your application on top of Google Wave. Unless your are building a clone of Wave for the sake of building a clone, it might provide you with a lot of the infrastructure you need.
I'd hate to sound harsh, but I think you might need to dig a bit deeper into the subject, and return when you have a more tangible question.
The non iframe like technologies are collectively called Comet, and since you didn't mention any specific language you want to use could try to use CometD which has recently been released and should you support in what you want to do. Or you just dig directly into Google Wave programming since it already seems to have everything you are looking for. Personally I always found all the iFrame solutions a little iffy.