There are several WYSIWYG editors out there, such as TinyMCE, CKEditor, etc. However, IMHO these editors don't have a nice and modern appearance like Froala. Problem is that Froala costs, and it sucks because this is just an internal app that I plan on using long-term without anyone else even looking at it.
TinyMCE and CKEditor also seem to have some pretty terrible themes. I'm ultimately wanting to get something inside of my ruby on rails application.
Does anyone know of any modern looking WYSIWYG editors that actually look like they were developed in the last 10 years? I have a beautiful theme for my rails app and I just don't want to kill it with some old looking theme.
Not looking to get flamed and yes I've googled, but I came here because I really can't find what I'm looking for and hoping someone else can shed some light.
I really don't see a whole lot of difference between Freola and TinyMCE, or the HTML editor this website uses.
Can you list specific features you're looking for that the items in the list don't do? I know you mentioned theming, but there are literally hundreds of themes for TinyMCE and you can roll your own without much effort at all.
The best WYSIWYG I've come across is Redactor. It costs $500 for a developer license:
There is a gem called redactor-rails which provides it for free (I don't know how).
It is the most efficient & good-looking I've come across.
If you want functionality with the likes of Paperclip etc, we've used CKEditor extensively. Yes, it looks crappy but I believe there are ways to style it:
I can give you the code we use if you want to try it. Once you get rid of 99% of the non-essential elements, it starts to look good.
Related
so yeah the title kinda says it all...
Bootstrap hurts my head as it seems impossible to make a form layout that is useful in the real world. Currently I am used the wizards in visual studio to make my forms... but it's impossible to display fields in a different column. Even do some type of format like we have here on this forum.
The picture below is something I would like to do... is this possible... I don't have telrik and I don't understand how to use those controls even If I did had them... but I saw stuff like that in my search.
I went to the bootstrap site.. well a few sites... one talk about the columns and stuff... the other had downloadable templates that looked nice... but there was not information on how to install them or even use them...
So what's the deal with bootstrap... Is there a site or something that breaks it down in a very simple way so that someone can understand it??
Thanks all.
Bootstrap's popularity is both their fortune and misfortune. Bootstrap is nothing more, nothing less, than a collection of commonly used elements and components for web development.
Keep in mind they came into being at a time when web development was more hectic and much more basic than today, when there were no stunning themes all over the place and developers had to style websites from top to bottom, including every last detail. And the differences between how each browser rendered them were much bigger than today.
They (Bootstrap) managed to develop a few components people could rely on. Columns that would keep their width and alignment over all browsers, images that would shrink, responsive layouts that would work in all devices and all browsers. If you inspect their solutions, most are ingenious and quite a few are "hacky" but hey, they worked!
Getting back to your question: the real problem with Bootstrap is that quite a few people misuse it, in the sense that, without knowing all of it and without taking the time to actually look at and understand the CSS rules behind it, they just apply classes over classes hoping it would work, cluttering the markup until it becomes unusable.
My advice?
Don't rush it.
When you need a component, start from the very markup Bootstrap provides. Inspect the elements and understand what you need to change in order to make it look/behave like you want. Also, always remember it's very popular. Whenever you want to do something different with a certain element, chances are someone tried it before, perhaps they didn't know how to do it and perhaps they shot a question on SO. And perhaps someone took the time to look at the CSS and do the mod properly.
From my perspective, as it is now, just by searching for high-voted answers on SO and using default examples from Bootstrap, you can solve 95% of anything you might want to achieve with it.
And when you get at the 5% you can't, come here and ask a question on Bootstrap that wasn't asked before. I bet you'll get very good answers and a lot of up-votes.
So you got nothing to lose. Best of luck!
I am very, very new to Rails development. I have read the arguments against using Rich Text editors that are WYSIWYG. For the purpose of making a CMS for my portfolio site, I can understand RedCloth and implement it.
My question is what happens when there is a lengthy post to be written, how does RedCloth make my job faster? Is there a scenario where Rich Text editors would be preferable?
Pardon me if this sounds ignorant. I want to understand what the best approach is to my situation.
Thank you,
Rishi
just initiated a little pro/cons list of both alternatives, feel free to contribute
WYSIWIG editors
pros:
really easy to set up (check ckeditor and this little gem for instance)
easy to use for anyone able to use Word... to some point
lets you insert any html code / script you want
cons:
the Redcloth site gives sound reasons why you shouldn't use WYSIWYG editors ; among them :
often generates bad, redundant, semanticaly incorrect html code
often lets your users mess up with your site's look and feel by defining their own styles, stuffed in html style attributes
may confuse your users, beacuse they don't know what happens "under the hood", in html ("why can't i just place this picture where i want, in the middle of this page ?")
Textile, Markdown, etc.
pros:
easy to learn, easy to use
usually a good incentive on users to produce semantically correct, structured documents
easy to sanitize, unless you need the html not to be escaped
does not mess with your sites style, unless you allow the user to use advanced features of the format
raw content is readable and well-structured
slightly less storage space needed for raw content
cons:
your users have to learn it, and some don't love it (but WYSIWYG-style UIs do exist to help them ; just look at the good job StackOverflow did with theirs)
for advanced features you have to know the format well
It is a personal choice, you should use whatever you feel is comfortable, especially when you have just started.
WYSIWYG editors are some times not advisable for more advanced users and for making special features, this is because they distance you from the actual source code and force you to work within their frame.
These editors are convenient and quick for simpler work exactly because they give a frame to work in.
Since its not like a code framework or library, you can always make a switch when you are at a point when the WYSIWYG editor you are using is beginning to limit you and get in your way. (only you will know this)
Before then go right ahead!
I've been reading up about HAML/SASS lately and I'm not quite sure why any one would not want to use it. It seems to be very easy to switch, makes things cleaner and more efficient.
Update:
What about using one or the other? Most of the complaints (the few complaints there are) I hear seem to be about HAML, would there be any problems mixing and matching XHTML/HAML and CSS/SASS?
Update:
Sorry, one final update to the question. It seems to me that switching back from SASS to CSS is painless and simple. What about switching back from HAML to HTML?
If you're using Rails, yes. Go for it. Some issues you will hit, though, will be that any other developer brought onto the team later will have to learn it, as well. If you're already working with a big Rails crowd, that's fine, but HAML/SASS may confuse a designer who's worked with pure HTML/CSS for years.
If you're not using Rails, though, a good HAML/SASS integrated system is hard to come by. There are a few out there, but I imagine they're not as well-supported or as far along with the spec.
But, yeah. HAML/SASS is definitely worth it. The only real issue you'll hit is that it's not yet standard.
As for mix-n-match, HAML and SASS are so similar in style that I'd say go for both, but it, again, comes down to personal preference. Try using both for a day, and if you don't like one of them, switch back. There's no technological issue about it, so do what you prefer.
There are lots of tools for working with HTML and CSS. The syntax isn't pretty, but the improvements from HAML and SASS don't seem that dramatic to me, and for many they're not worth the trouble. Of course, for those developing web application with widely differing frameworks (differing from Rails that is) it's even harder to find a reason to go to the pain of integrating something so foreign. (Example: care to explain what I'd have to do to integrate SASS into my Java/Stripes/JSP environment? :-)
I've been on volunteer projects where HAML's syntax curve (syntactical whitespace, the automatic generation of tags etc) has been seen as a barrier: one more thing for a programmer new to the project to learn.
Personally, I think SASS is worth it, but I'm up in the air about HAML: having debugged HAML templates before it seems like the typing you don't have to do with HAML is overcome by the time you spend debugging why there's an error on your templates. This could be a (HAML) newbie's perspective though.
I'm inclined to agree with the question; it is easy to switch, the syntax isn't that complicated, and it does make things cleaner and more efficient. It also makes it harder to unwittingly generate invalid HTML.
I also think the learning curve is shallow enough that a programmer that can't handle it, is probably a programmer you are better off without on your team. That might sound harsh, but I believe it.
The only cons I can see would be if you are developing in ASP.NET or something where retrofitting Haml and Sass would be a pain, is way unexpected for anyone else used to the platform, and possible a chore to maintain in a production environment. On Rails though, go for it.
I don't think that using HAML ever adds much benefit to a project.
SASS, on the other hand, effectively introduces variables and computations and other really useful features that save you time and effort in the long run on larger projects.
Using SASS is incredibly smart with any project that's larger than just a simple one-page form.
I tried using SASS but found that editing CSS using MacRabitt's CSSEdit (Mac Only) was way easier and more efficient for the way I work. I'm a very visual person and like to have a live preview when making changes to style sheets and didn't feel like investing a ton of time into something I wasn't having a problem with.
One thing most people don't realize is that HAML sucks for content. It's great for structural markup, but don't try and push it too far. (You can mix & match HTML in your HAML file, too!)
Sass is absolutely indispensable, especially in the long run. It's not just about writing the stylesheets when you have it all in your head, but about maintaining them down the road. The new Sass3 takes the syntax question out of the equation: you can take your pick if you prefer the curly-bracey SCSS syntax.
HAML/SASS may indeed be awesome to use, but they do introduce dependencies both technical and knowledge-oriented. This may not be an issue if your dev and prod environments are controlled and predictable enough, with newbies receiving enough training (or being vetted for subject knowledge on the way into the organization) to hit the ground running, but all of that is overhead to be acknowledged.
why is this..
%p
hello world
better than this..?
<p>hello world</p>
clue.. If you aren't doing ruby, it isn't. Unfortunately adding closing tags and braces isn't really the most challenging aspect of making webpages, so most professionals wouldn't really care. Use whichever you prefer.
From a developer's perspective, Haml and Sass absolutely rock. However: from a designer's perspective, Haml and Sass might not be readable. It really depends on who is on your team.
If it's a bunch of developers and/or designers who aren't afraid to learn a DSL, then absolutely go for it.
If you have a mixed team where designers toss their CSS and HTML work to developers who translate that to Haml/Sass, sure.
If you have a design team that passes work to the developers AND the work flows back to the designers, you may not want to use this because the designers might not be able to use their tools to edit the files.
If you have a small team where marketing and business people need to edit the web pages and they only know HTML and a light bit of CSS, then you probably shouldn't use Haml/Sass.
However you can't really make a blanket statement here. Consider that at least with Rails you can mix the template types in your views. So, some of your templates can be plain HTML stuck in .erb files, and other pages are .haml files. You can have partials be of one type inserted into templates of another. (I think mixing types is probably a bad practice, but if you just need to "get the job done" then it's an option.)
I am using SASS on a Django project right now. I like it and am going to continue using it. One problem I've found however is that error messages aren't always particularly intuitive, particularly if you leave off a }.
Which one is better and ideal in a web based application?
Edit:
Actually I am developing a community site. So the level of users may vary. Heard about XSS security issues with WYSIWYG editors. Also I am not familiar with WYSIWYM editors and its features. As far as I know the features in WYSIWYM editor is less compared to the other one. I figured one named as "WMD: The Wysiwym Markdown Editor". Its quite easy to use.
So security and ease of usability should be there. In such a situation which editor will be better.
If your users can handle WYSIWYM, I'd go with that.
I'm considering your system will be visual, that is, if you say something is a title it'll look like a title (otherwise the WYS part wouldn't apply). If the user has to manually type markup, then only the most savvy or technical users will be able to handle it.
What I've seen with most users is that they have trouble giving meaning to what they want in a document. They don't think "this is a title", they think "this should be bigger and bold". People that cannot think "this is a title" can't handle a WYSIWYM or they'll find it hard.
Who is going to be your user base? If it's people writing academic papers I'd go with WYSIWYM because they'll have no trouble handling it. If it's for house wives writing recipes, they may not be able to handle it or they'll find it so hard that they'll decide it's not worth the effort.
For me the ideal is WYSIWYM, but do it only if you think your target users will be able to handle it, otherwise you'll have to go with WYSIWYG.
I personally love the WYSIWYM mechanism. I use it for my own work as much as possible. I like it so much that I try to get others to try it too.
Boy, that goes over like a fart in a space-suit.
My cynical self assumes this to mean that most folks are ruined by tools like Word. Everyone knows to make a meaningful document. They also know what a meaningful document looks like. If it doesn't look like that, the tool is wrong! What's actually happening is these document producers don't actually know what they mean, and are used to hiding that fact with pretty borders and adjusting tab-stops.
What I really think is happening, though, is that these folks who are resistant to WYSIWYM are that way because it's a harder way of thinking about something they already invested in learning. This is a level of abstraction above WYSIWYG, though not quite as far removed as composing documents in markup like LaTeX or HTML. And since they can already create any sort of document in a tool that requires no abstraction, it's just a hard sell.
That being said, I think you should force WYSIWYM on your users if that is feasable. There are some good reasons for this
All of the benefits that naturally come with two stage composition. Formatting is not decidable until the document is composed, so any time spent before the document is finished on formatting is time wasted. Get it composed quickly.
The document is marked up with semantic information. This can be used in searches, or for other tasks that strictly visual markup cannot. This is especially useful for accessibility.
By depriving your users of arbitrary formatting decisions, all of your documents will follow company branding. Everything will be in a standard font and color. All text will use the same spacing and height. It will look to readers like it came from a single entity.
Check this
http://www.wymeditor.org/
Could you be a bit more specific? What kind of web application? How many users? Who will the users be?
In general though I've had quite of bit of experience implementing WYSIWYG editors for various CMSs and found them to be quite problematic because clients often like to go wild with formatting their content repeatedly over and over again and often end up having the editor generate HTML of poor quality. This causes all sorts of layout issues or simply pages that look really messy because everyone likes to fancy themselves as graphic designers.
If done properly WYSIWYG can work very well, but it is more work to really get it right, especially when taking into consideration CSS. Most of the good editors are nicely configurable and allow to specify just how much control to give the client over visual formatting.
As for the quality of the code they generate, tools such as FCKEditor and TinyMCE are very mature and do a good job of editing out the irrelevant crud in the source code, but be prepared to provide support for clients using a WYSIWYG when their content doesn't look the way they would like it to.
Since WYSIWYM editors are much like WYSIWYG with structural formatting instead of visual formatting, philosophically I think they are better and less problem prone. So if the client doesn't have a need to visually format the content I think WYSIWYM is bound to cause less headaches down the road.
The editor used here in Stack Overflow is a good example of restrained WYSIWYG. You can format the content visually but only to a certain extent.
If your users a tech savy and understand how the basics of markup go and you think they will feel more empowered using WYSIWYM, then use that. If your application is going to be used to people who have little technical knowledge, use WYSIWYG.
Unless you are doing a tool for print layout (i.e. Indesign or maybe a mailing list printing tool) you are probably better to stick with WYSIWYM.
It is likely to be easier to implement
Web browsers are highly configurable and you may not have fine grained control over items like font size.
The structure is explicit so rendering to different media is comparatively easy.
It avoids the temptation on the part of users to over-design the document or whatever they are entering.
Document structure facilitates indexing, table-of-contents generation and cross-referencing where this is relevant. Compare (for example) maintianing a large index in Word with doing in LaTeX or Framemaker.
Anecdotal experience from LaTeX users (in particular) suggests that organising a document by structure is likely to produce a better document.
From my experience with MYSIWYM, I was very seduced by the idea and the looks, but I was then deceived to know that the editor didn't give me a simple and efficient way to restrict the user, for example the user can insert images inside paragraphs... and I don't want that... I want more control over what the user can do.
I'm looking for a more attractive alternative to the standard scaffold.css?
Has anyone come across a stylesheet that was specifically designed as a more attractive, less sparse alternative to the built-in scaffold.css?
I'm going to assume the others are answering the wrong question with their focus on scaffold generation and guess that you really just want more attractive css.
I'd suggest blueprint css framework which has fairly attractive defaults. It's not specificly designed to replace scaffold.css but it doesn't take much to make it work.
You honestly don't need one. Why? Because you're not supposed to be using that. A scaffold is precisely what it is, something there to help you while you're building your app, but not a system for the long term.
However, if you just want something that doesn't look like the graduate class at Playskool My First Web App produced, try Ryan Bate's (Railscasts Guy) Nifty Generator gem at http://github.com/ryanb/nifty-generators/tree/master. Not only does it look slightly better, but it has some nifty extras built into it.