I'm trying to implement my own little reader view app (an app that would do the same thing as reader-mode on safari), and there are a few things I find asking myself:
Is there a technical term for this feature (reader-view doesn't really cut it)?
Is there a standard that websites are supposed to follow in order to indicate the content they would like to have in their reader views
Is there an open-source set of HTML parsing rules to pull the "readable" content from a website?
Is the effort to implement such a thing simply too big for a single person in a few weeks and if so should I opt for services such as Instaparser?
I believe the original to be implemented by arc90, and they called it readability. You can check out their page here.
It's been ported to many different languages over time, so you could take a look at the different implementations to learn more about it, how it's done etc.
Python readability
JReadability
JavaScript
Ruby
This is just a small sample here, there's many more examples if you would like to find more.
Edit: Oops, after some more Googling I found this question with an answer that explains it very well.
Related
Context: Ok so I am building a website for a friend. Hes a designer with a high need to daily include his projects (images and text).
Problem:
Ok so I know pretty much how to code in html/css/javascript a front end responsive website, that is the easy part for me, the hard one is the content page. I've never done it so I don't know the best way.
A page that he goes daily put a new project, new images, formatted text (A like a blog). But since he doesn't know anything about coding and front end, it has to be simple enough for him to understand.
Resources: I made several searches and found some websites that allow custom templates with content, one of them standing is wordPress (haven't used it for years). I am currently abusing tumblr for that matter, but their support is quite bad. Should I use one, should I buy a host like bluehost and create my self one, what you guys recommend? I tried google it but perhaps I am not doing it the right way since I am not finding any answer to my problem.
Look, you've come to a programming website, so the most common suggestion you'll get here, and the option I myself recommend is:
MAKE IT YOURSELF!
It really is a fun and very educational experience.
There are many, many ways to do this. In general you'll want to have a front end that communicates with a back end API.
For the front end, there are a lot of options. From templating engines like Jekyll, to MVC frameworks like Laravel, to full fledged high level abstractions like Angular and React, which are admitedly harder to learn but so, so robust, and useful once you've figured them out.
The selection of tools you can use to make the API that supports the website is just as rich. There is ASP.NET for C# (which some people use for the front end as well but I wouldn't), there is Node.JS for JavaScript, with a myriad of libraries and packages to get you started. Flask is a popular option for Python. The list goes on and on.
Oh and dont forget about Ruby on Rails.
As for the interface which your friend will use to add their work, turning all that complicated back end into a simple, easy to use interface is a fundamental part of UX design and, IMHO, quite satisfying once you get it right. Make it sleek and, most of all, intuitive. One shouldn't have to be taught how to use it. It should be apparent from the first time they open the page. You should always ask for their feedback as you are developing it. Some even opt to create mock ups of the interface, in order to get feedback on both its aesthetics and its intuitiveness before a single line of code has been written.
Now, regarding how you'll actually do it, the answer really depends on the tools you opt to use. In general, you'll want to read up on things like the MVC pattern, or React's component architecture. The former is something you'll come across on a wide variety of platforms. The latter is mostly React specific, but in my opinion, understanding how to properly build a website using component architecture means you're in the right mindset, something that will help you no matter how you choose to build it.
All that being said...
Web development is complicated. Creating dynamic websites is a much larger undertaking that designing a static page, or even making an SPA. Though I do wholeheartedly recommend you do it at some point, starting with your friend's website might not be the best idea. Or, you may simply not have the time to sift through all your options, figure out which is best for you, begin the learning process etc.
In that case, there are plenty of publishing frameworks and tool sets to choose from. Wordpress has become very popular in the recent years, and templates and plugins for it are abundant. Alternatives like Medium and Ghost have also gained some traction.
There are plenty of commercial CMS type frameworks. One I have heard good things about is ExpressionEngine. However, I cannot speak for it with certainty.
If you are looking for a website builder, there are also plenty of options out there such as Weebly, Wix, as well as Squarespace. Google sites is a relative newcomer in that department, but seems promising.
So, in summary,
I wholeheartedly recommend building it from scratch. There are many, many languages, frameworks, and tools out there you can choose from, each with its own patterns, best practices and idiosyncrasies. If you lack the time, or simply don't feel like going through that process of building a dynamic website from scratch, you can use one of many tools available. However, that wouldn't be nearly as much fun, and would likely produce an inferior result.
I have been developing a web application which has many documents (.pdf format) which must be embedded on the site. After doing a little research, there seem to be many "services" and/or "libraries" which allow the same functionality as the <object> tag combined with an Adobe Reader plugin.
Some examples include Crocodoc.com as well as PDFobject. Although, I will admit, a side by side comparison of these two SaaS, Crocodoc would take the lead.
It has been well known for awhile now that <embed> coding is outdated, and the best methodology for .PDF implementation is the <object> tag, in a previous discussion located here on SO.
However, one does not dispute that from a basic implementation approach of having standard-pdf bookmarks, links, and a 'table of contents', it appears that the browsers built in (downloaded, whatever...) Adobe Reader plugin provides the same functionality as one of the many plug-ins or extensible libraries provided on the web.
I would like to approach all the wonderful experts here on SO to provide an objective approach to the pro's and con's of using such methodology. Feel free to use subjective opinions, but please back them with facts and a well researched answer. Thank you.
Edit
After being approached on the topic that subjective answers are not suitable for StackOverflow, please keep in mind any subjective opions must be backed by a fully endowed, truthful basis behind any possible conclusion. Every programmer and web designer implements in their own ways because of experiences as well as pros&cons, so in order to provide the best suited answer.... "When In Rome"....
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Like, can I write a business strength application in HTML5 that mimics our current system that contains many highly interactive grids, custom trees and so on.
We have a good working system written in C# WinForms with parts done in WPF and have recently embarked on writing a custom app for the iPad that communicates through WCF with our main server hosts. We now have a very fast custom grid written in C# that compiles to Objective C through MonoTouch and also a cool interactive pie chart.
Now my boss wishes to build a version for Android and I am thinking if we shouldn't really be spending time creating a single HTML5 app that can run on both iPad and Android equivalents.
Thing is - take a grid - my grid on the iPad is fast (re-usable cells etc) - how would I create a grid from a 'dataset' type source in html5? Do I really have to go down creating lots of tags and then submitting them to the browser? Are third party widgets like jqwidgets the answer??
Thanks
This is a bit anecdotal, but my experience has been that HTML5/JavaScript are just not fast enough on mobile devices yet (in 2012) particularly if you are displaying lots of data, especially and you want fast response times with interactive features. Give it another year, and I wouldn't be surprised if this statement becomes outdated as mobile devices continue to evolve.
Mobile web development certainly has its uses currently, e.g., if you want to target the most devices with a single codebase; if you don't have enough development resources and are willing to settle for a non-native experience; if you don't have experience in the languages required for native development, etc.
Given that you already have done the work for the iPhone app, my humble opinion is that it's probably better to move forward with a native Android application -- you will get a much more responsive application for about the same amount of work at this point.
how would I create a grid from a 'dataset' type source in html5?
Depending on what the grid contains, you can do it with plain old HTML tables or with a combination of other elements styled with CSS. There are really many more considerations though-- e.g., does it need to work on small screens (e.g., phones) or just larger screens (tablets). Often, you can't really fit a whole grid on a small screen, so you end up with UIs that aren't really grids anymore. You can take a look at a mobile JavaScript framework such as jQuery Mobile to see how they've done it and maybe even consider using the framework for use in your own application.
The various JavaScript frameworks (eg. JQuery and Dojo) have mobile device-specific widgets of quite high quality. Have a look at http://dojotoolkit.org/features/mobile and http://jquerymobile.com/
How close do these get to native apps developed in ObjectiveC and Java? Not perfect but maybe good enough. You can also use a combination of native and HTML in the same app, some pages native some HTML. I'm doing that kind of thing with IBM's Worklight, but then I would, I work for IBM ;-) Irrespective of specific products I do see folks taking that approach.
In addition to portability, anoyther of the benefits of having much of the app in HTML is that updated versions can be delivered without going via an app-store - this increases agility of functional delivery.
As evidence, I'd say that a lot of Windows 8's apps are just wrapped JS/CSS/HTML, with a few APIs which Microsoft supplies to allow access to hardware/the filesystem.
I wouldn't think that they've gone so far as to make Excel 2013 JS-based...
...however, with that said, they have gone so far as to allow developers to extend their programs with applet views of the data -- those applets are all going to be built on "html5" (again with an MS-Office JS API).
It's not an easy road to go down -- people look to jQuery to be their saviour for these types of things.
This is exactly where jQuery would not be what you wanted, if you were looking to hack together a solution.
For example:
$(".table_cell").click(function () { alert(/*whatever*/); });
People think that jQuery is assigning a delegator to listen to any click on any element containing class="table_cell".
That's really not what it's doing.
It's looping through each one, and attaching an event-listener to each one, directly.
It's these little things that people miss -- people like Twitter, who didn't bother caching references to elements, because jQuery is so easy to hack things together with.
So then you have JS touching (or acting on) dozens or hundreds of individual elements, at all times.
That's not good for anyone.
jQuery isn't bad at all -- it's quite helpful, as a low-level construct to help skirt around browser differences.
Some of its plugins are also all right.
I can't guarantee that they're all high-performing answers to all things.
But some of the plugin-creators understand how to maintain a responsive and well-performing program.
Which ones are right for your exact needs? Who knows, other than you.
Will they perform perfectly, and quickly?
That depends on a lot of different things, of course.
Coming from C#, you might do to look at something like AngularJS.
Angular, itself, uses an internal version of jQuery, to tackle some of the low-level stuff that jQuery has made a solved-problem.
But it allows for data-binding, and pretty simple view templating.
Hammer.js is also a very decent gesture-tracking library.
From there, though, I'd suggest building your own framework, if you want it done the way that you want it to be done.
Nobody knows what your needs are but you, and trying to stuff things into a shoebox, because it's available, isn't always the solution, regardless of what various companies may think...
You can leave most of the node-work to Angular, you can leave the gesture-sensing to Hammer, you can pull out some other basics from jQuery-lite (the no-frills jQ installed inside of Angular, if you don't have jQ on your site), or jQ, itself...
But they're just tools and not answers.
The web can be very responsive if you cache references to elements, rather than querying for them over and over, delegate events, do large structure-changes off-DOM (on cloned-nodes, if necessary), and don't try to treat JS as a traditional inheritance-heavy language, and you remain mindful of how and when to use AJAX (number/frequency of calls versus size of data -- favour fewer calls).
I am pretty new to developing softwares and am intrigued by the huge world out there!! I have working knowledge of C/C++ and Java.. I was thinking of making an application that would convert a webpage to a pdf document.. I know there are many solutions available -- both online and offline..But I want to develop my own.. I googled but couldn't find anything that would help me get started..
I want to know how do we go about a conversion process?? How to get started?? What languages and technologies are pre-requisites for making a converter like this??
Thank You
So at least you need to get to the bottom to following specifications:
HTML specification
CSS specification
JavaScript specification
PDF specification
Moreover here are a lot of minor stuff such as Fonts, Decription/Encription algorithms and many many other minor but still necessary things.
I think you can imagine that this is quite a long way to get all this working. In fact, the complexity of such software is the reason why so many companies make money in this field.
Anyway, I'd suggest you to start from the simple things and grow your software gradually. Start with converting HTML to Image, because it is a bit simpler. Take and parse HTML, its CSS, its JavaScript. Clean HTML. Build DOM of the HTML document. Apply styles. Go thru the DOM and draw elements to the image.
Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm supposed to do a presentation for my co-workers on a web framework I evaluated. These people are developers and hate long and boring PowerPoint stuff, so I got lots of little code snippets. I also put together a small sample application. My question is, how do I present the code so people can follow?
Some things I thought of:
Put the code on PowerPoint slides, looks pretty bad and unless it's an image I can't get syntax highlighting to work. Having my code in images is a pain and doesn't scale well to different resolutions.
I played around with the S5 XHTML presentation format and integrated a JavaScript syntax highlighter. It's a bit clunky but workable (I'll get some grief for ignoring the company's CI for presentations since I wouldn't use their templates. Don't even ask...)
I could put together a script (notes) and "live-code" in front of my audience. I don't like this so much because it keeps me so busy that it's hard for me to give a good explanation while I write. And there's also a high chance of me causing errors and make them wait.
A screencast? But then I wouldn't have to be there... Maybe narrate it?
So what would you do?
I could put together a script and
"live-code" in front of my audience. I
don't like this so much because it
keeps me so busy that it's hard for me
to give a good explanation while I
write. And there's also a high chance
of me causing errors and make them
wait.
I like this option, if you can get your demo streamlined to the point of not holding up the audience. You can do what TV cooks do when the recipe takes more time than they have; start the coding, then jump ahead to one that's 90% or 100% done.
If you have a colleague you can get up to speed, you can have them do the coding while you talk and point out what they're doing.
You can use your IDE, which will give the syntax highlighting and show your audience how to compile, deploy, test, etc. I would recommend using an oversized font though, just for the session, so that everyone can see.
Does your IDE allow opening/closing regions or code segments? In Visual Studio you can create code regions that you can expand or collapse. If your IDE has the ability to do this you could create your code samples as regions and then open/close them as you go through your presentation. You could switch back and forth between your presentation and code samples in the IDE, but wouldn't have to code on the fly. Using open/close allows you to hide the code you're not referencing to keep things less cluttered.
I actually saw this done at Agile 2008 and it seemed to work pretty well.
You can only fit so much information on a PowerPoint slide but that's actually a good thing: people can only look at a certain amount of information and get something meaningful from it.
So if you can't fit it on a PowerPoint slide, you need to rethink your approach.
Code snippets are good. They don't need to be highlighted. Just put them in Courier New (or some other fixed width font) and it'll come across as code. Code snippets don't have to be complete either. Just boil them down to the essential concepts (using comments or ellipses to indicate missing code).
Programmers being programmers, they'll probably ask questions when it gets to the technical, which is good.
Also, if the programmers are familiar with something similar try and relate all the concepts back to what they know. It makes it easier to grasp. Like if you're explaining Spring MVC and they know Struts, explain the Struts equivalents. It can be useful to put that sort of thing in table form (even as a handout).
That's what I did for exactly that (a Spring MVC primer for Struts programmers).
If you want your audience to see a lot of code snippets, especially lengthy ones, you could print them out as handouts or provide them as notes in PDF or text files (people can follow along on their laptops).
Actual presentation slides should contain the smallest amount of text (including code) necessary to convey your ideas. If there's a lot to read from a distance, your audience will get tired after awhile and might have trouble following along. Let people read the full code sections on their own laptops or handouts, while calling attention to just the critical parts in your presentation slides or script.
If they don't like Powerpoint, don't use use it. We use Camtasia screen recording to record 'live' demos for presentation to customers (live in quotes since it doesn't have the disadvantage of crashing halfway through your presentation :-). They always prefer to see it in action rather than what they think is fudged functionality.
It's pause-able like your Powerpoint slides and has the advantage of syntax coloring since you just record bringing your up in your favorite editor. It's also dynamic which is much better than Powerpoint (although I've seen some people do crude animation with multiple Powerpoint slides, always funny to watch in action).
This basically maps to your screencast idea but, if you want a reason to be there, do a large number of small screencasts to show interspersed between your real presentation, narrating (in person, not on the screencast) if necessary.
Personally, I'd prefer to send a fully narrated Camtasia off to the target audience but that's because I'm not totally over my early-career phobia of public speaking :-).
In a pinch, you could do a real live demo since your audience (is videance the equivalent for video presentations?) are programmers and will understand any problems you have.
I had this done to me, and thought that it was the best possible solution:
Get another person to help you out. While you are talking about the code, let the helper type the code. This way everyone in the room will be looking at the code, while listening to you explain it.
This of course involves finding someone who can help out, and understand the code just as well as you do. But the results can be great.
If you could do it all in a screencast and you wouldn't have to be there, then do a screencast and don't be there. Nobody complains when a meeting gets canceled. Just distribute the video, maybe with an accompanying report with notes or links so people can read more about the tools you're demonstrating.
And you'll get more credit later as your co-workers and managers talk to other people: "Hey, did you see the presentation Bibac did? No? You should; I'll send you the address after lunch."
If you're demonstrating code in the presentation, then also consider having the finished project available so people can try it for themselves.
When I give presentations involving Visual Studio I put code snippets on the general tab of the toolbox. During the presentation I drop/drag these code snippets into a code file, markup page, etc.